AD-A270  616 

llllllllii 


Formalizing  Properties  of  Agents 


DTIC 

ELECTE  ■ 
OCT  14 1993 

A 


D 


Richard  Goodwin 
May  1993 
CMU-CS-93-159 


School  of  Computer  Science 
Carnegie  Mellon  University 
Pittsbuigh,PAl5213 


Abstract 

There  is  a  wide  gulf  between  the  fomal  logics  used  by  logicians  to  describe  agents 
and  the  informal  vocabulary  used  by  people  who  actually  build  robotic  or  software 
agents.  In  an  effort  to  help  bridge  the  gap,  this  report  applies  techniques  borrowed 
from  the  field  of  formal  software  methods  to  develop  a  common  vocabulary. 
Terms  useful  for  discussing  agents  are  given  fonnal  definitions.  A  framework  for 
describing  agents,  tasks  and  environments  is  developed  using  the  Z  specification 
language.  The  terms  successful,  capable,  reactive,  rcllexive,  perceptive,  predictive, 
interpretive,  rational  and  sound  are  then  defined  in  terms  of  this  framework.  In 
addition,  a  hierarchy  for  characterizing  tasks  is  given.  The  aim  of  this  report  is  to 
develop  a  precise  vocabulary  for  discussing  and  comparing  agents. 
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Introduction 


In  the  artificial  intelligence  community,  it  has  become  common  to  talk  about 
agents  that  perform  tasks  and  to  describe  such  agents  in  terms  of  characteristics 
that  would  allow  them  to  be  successful.  Common  terms  include;  successful, 
capable,  perceptive  and  reactive.  Each  of  these  terms  has  an  intuitive  meaning  that 
allows  for  informal  discussion  of  the  suitability  of  an  agent  for  a  task.  The  problem 
with  these  informal  definitions  is  that  they  are  often  ambiguous  and  incomplete. 
What  is  needed  are  more  precise  definitions  that  will  help  to  establish  a  common, 
uniform  vocabulary  for  talking  about  agents,  environments  and  tasks. 

This  paper  formally  defines  some  useful  terms  for  discussing  agents.  First, 
a  general  framework  for  describing  agents,  tasks  and  environments  is  developed 
using  the  Z  specification  language  [Spivey,  1989).  This  framework  is  useful 
for  analyzing  agents  and  communicating  ideas,  but  is  not  intended  to  suggest 
representations  or  algorithms  for  implementing  agents.  Through  developing  the 
framework,  a  number  of  key  issues  are  identified.  Agent  properties  are  then  defined 
in  terms  of  this  general  framework. 

Overview 

An  agent  is  an  entity  created  to  perform  some  task  or  set  of  tasks.  Any  property 
of  an  agent  must  therefore  be  defined  in  terms  of  the  task  and  the  environment 
in  which  the  task  is  to  be  performed.  The  most  basic  question  that  can  be  asked 
is  whether  the  agent  achieves  the  task  or  not.  Is  the  agent  successful?  Other 
properties  concern  the  suitability  of  various  components  of  the  agent  and  can  be 
defined  in  terms  of  success. 

The  operational  problem  is  how  to  determine  if  an  agent  is  successful.  The 
approach  adopted  here  is  to  take  the  lead  of  the  behavioural  psychologists  and  make 
observable  behaviour  the  only  criteria  allowed  for  determining  success  [Skinner, 
19741.  Such  an  approach  allows  us  to  avoid  having  to  make  inferences  about  the 
agent’s  beliefs,  intentions  or  motives.  Using  a  behaviourist  approach  does  limit  the 
types  of  tasks  that  can  be  considered.  Any  task  where  success  depends  on  inferring 
or  interpreting  the  agent’s  internal  state  are  ruled  out.  Tasks  of  this  type  would 
have  to  be  modified  so  that  any  internal  state  of  interest  is  manifested  as  external 
behaviour.  For  example,  suppose  the  task  were  to  go  outside  and  determine  if  it 
is  raining.  Even  if  we  observed  the  agent  going  outside  and  getting  wet,  there 
is  no  way  to  know  whether  the  agent  believes  that  it  is  raining.  To  make  the 
task  operational,  it  could  be  modified  to  have  the  agent  open  its  umbrella,  if  it  is 

I 


raining.  To  determine  whether  the  agent  is  successful,  we  only  have  to  observe  its 
behaviour.  If  it  opens  the  umbrella  at  the  appropriate  times,  it  is  successful.  We 
don’t  have  to  ascribe  any  belief  about  rain  to  the  agent. 

Since  success  is  the  fundamental  property  for  characterizing  agents,  some 
appropriate  scale  is  needed  for  determining  success.  The  simplest  scale  that  can  be 
used  is  binary:  An  agent  is  either  successful  or  not.  A  binary  scale  for  success  leads 
to  binary  definitions  of  other  properties.  For  instance,  an  agent  is  either  capable 
or  not  and  there  is  no  way  to  compare  relative  capability  of  agents.  The  scale  for 
measuring  success  can  be  refined  to  give  a  numeric  value  to  the  quality  of  task 
achievement.  In  economics,  such  a  numeric  measure  of  quality  corresponds  to  a 
utility  function  defined  over  the  possible  task  completions  [Raiffa,  1 9681.  Further, 
the  likelihood  of  possible  initial  conditions  and  external  influences  can  be  taken 
into  account  to  give  a  measure  of  the  expected  success  of  the  agent.  Refining  the 
measure  of  success  allows  corresponding  refinements  in  agent  properties  defined 
in  terms  of  success. 

Although  a  behaviourist  approach  is  being  adopted  for  measuring  success,  it  is 
sometimes  useful  to  consider  the  internal  organization  of  the  agent  and  the  extent 
to  which  that  organization  leads  to  behaviour  that  results  in  success.  A  particularly 
interesting  class  of  agents  are  those  that  maintain  some  internal  model  of  the  world 
and  reason  about  the  results  of  their  actions.  Such  deliberative  agents  attempt  to 
choose  actions  that  are  more  likely  to  lead  to  success  based  on  their  world  models. 
Additional  properties  for  a  deliberative  agent  relate  to  how  accurate  the  agent’s 
models  are  and  whether  the  agent  behaves  consistently  with  its  models. 

Informal  Definitions 

The  informal  definitions  given  in  Figures  1  and  2  are  derived  from  the  set  of 
characteri.stics  that  Mitchell  believes  are  necessary  for  a  successful  agent  iMitchell, 
19901  '.  These  informal  definitions  provide  the  intuitive  meaning  for  the  agent 
properties  that  will  be  more  precisely  defined  in  the  rest  of  this  paper. 


Issues 

Before  delving  into  the  details  of  the  definitions,  we  present  a  set  of  issues  that  any 
specification  in  this  area  must  address.  Then,  with  these  issues  in  mind,  we  will 
present  the  approach  that  we  have  taken. 

'Contains  references  to  Reactive,  perceptive  and  correct.  Some  additional  terms  were  described 
through  personal  communication. 
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Figure  2;  Deliberative  Agent  Properties 

Any  formal  definition  of  agent  properties  must  include  a  framework  for  de¬ 
scribing  an  agent,  a  task  and  an  environment.  To  say  that  an  agent  is  successful  at 
a  particular  task  in  a  particular  environment,  some  method  is  needed  for  specifying 
the  agent,  the  task  and  the  environment.  The  framework  for  these  descriptions 
must  be  sufficiently  detailed  to  allow  the  distinction  between  successful  and  un¬ 
successful  agents  to  be  made.  At  the  same  time,  the  framework  must  be  general 
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enough  to  permit  a  wide  range  of  agents,  tasks  and  environments  to  be  specified. 
In  designing  the  framework,  the  range  of  possible  tasks  and  environments  needs 
to  be  considered.  The  kinds  of  tasks  can  include  tasks  of  achievement,  tasks  of 
maintenance  and  tasks  with  deadlines.  The  environment  can  be  static  or  dynamic, 
can  include  other  agents  and  can  be  non-deterministic.  In  addition,  we  also  have 
to  consider  how  to  represent  the  interaction  of  the  agent  with  the  environment  over 
time. 

One  aim  of  this  specification  is  to  be  able  to  compare  different  agents  per¬ 
forming  the  same  task  in  same  environment.  Clearly,  to  compare  agents,  we  must 
distinguish  between  the  agent  and  the  environment.  For  a  physical  agent,  such  as 
a  robot,  the  distinction  between  the  agent  and  the  environment  is  reasonably  clear, 
although,  this  is  not  always  the  case.  What  happens  if  a  part  of  the  robot  breaks 
off?  Is  this  broken  piece  still  part  of  the  agent?  Furthermore,  is  the  resulting 
robot  the  same  “agent”  as  before?  For  software  agents,  the  distinction  between  the 
environment  and  the  agent  may  be  harder  to  make.  Fortunately,  this  question  is 
mostly  of  academic  interest.  In  general,  where  to  draw  the  line  between  the  agent 
and  the  environment  will  be  clear.  The  environment  is  everything  present  before 
the  agent  was  built  and  the  agent  is  everything  that  was  added. 

Of  more  concern  is  whether  and  where  to  make  distinctions  within  the  agent, 
since  such  distinctions  impact  the  definitions  of  agent  properties  more  directly. 
One  extreme  possibility  is  to  regard  the  agent  as  a  black  box.  This  is  sufficient 
for  defining  some  properties  of  an  agent,  but  not  others.  In  particular,  there  is 
no  way  of  describing  the  suitability  of  the  agent’s  effectors  or  sensors  for  a  task 
separately  from  the  entire  agent.  The  distinctions  that  should  be  made  are  those 
that  are  useful  for  comparing  and  designing  agents.  Distinctions  should  also  be 
sufficiently  abstract  as  to  be  able  to  apply  to  a  wide  range  of  agents. 

Given  distinctions  between  the  environment  and  the  agent,  and  between  the 
sub-parts  of  the  agent,  a  method  is  needed  to  describe  how  these  components 
interact.  The  agent  affects  the  environment  through  its  actions  and  is  affected  by 
changes  in  the  environment.  Sub-parts  of  the  agent  interact  either  physically  or 
by  passing  information.  These  interactions  should  be  characterized  to  the  level  of 
detail  necessary  to  make  useful  comparisons  between  behaviour. 

When  performing  a  task,  the  interactions  between  the  agent  and  the  environ¬ 
ment  occur  over  a  period  of  time.  So,  in  addition  to  representing  the  form  of  the 
interaction,  the  evolution  of  the  interaction  over  time  must  also  be  represented. 
Time  can  either  be  modeled  as  a  continuous  quantity  or  as  discrete  intervals.  Of 
course,  as  the  size  of  each  time  interval  shrinks,  a  discrete  representation  better 
approximates  the  continuous  quantity. 

Finally,  we  need  to  consider  whether  our  model  of  the  environment  will  include 
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non-determinism.  We  could  adopt  the  Newtonian  view  that  the  world  is  determin¬ 
istic,  if  only  we  know  its  state  in  infinite  detail.  Any  apparent  non-determinism  is 
the  result  of  our  limited  information  about  the  current  state  and  our  limited  ability 
to  compute  future  consequences. 

Neglecting  computational  limits,  the  environment  may  still  be  non-delerministic 
if  we  allow  for  other  agents  with  free  will.  Either  we  can  distinguish  other  agents 
from  the  environment  and  model  them  as  non-deterministic  entities  or  leave  them 
as  part  of  the  environment  and  include  non-determinism  in  the  environment.  If  our 
aim  were  to  define  properties  of  co-operating  agents,  then  the  distinction  between 
other  agents  and  the  environment  is  needed.  Since  this  is  not  our  current  objective, 
the  distinction  between  other  agents  and  the  environment  will  not  be  made  in  order 
to  simplify  the  framework. 


Framework 


Figure  3:  Agent  System  Overview 

The  general  framework  adopted  is  shown  in  figure  3.  We  make  the  necessary 
distinction  between  the  agent  and  the  environment  in  which  it  is  situated.  The 
environment  will  include  non-determinism  and  time  will  be  measured  in  discrete 
intervals.  Within  the  agent,  we  distinguish  the  mechanism  from  the  controller.  The 
mechanism  consists  of  the  sensors  and  effectors  that  allow  the  agent  to  interact 
with  the  environment.  The  controller  is.  conceptually  at  least,  the  component 
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that  accepts  input  from  the  sensors  and  controls  the  i’ffectors.  The  controller  may 
maintain  some  state  (memory).  The  details  of  the  nature  of  the  environment, 
the  structure  and  implementation  of  the  agent  and  the  agent’s  control  have  been 
abstracted  away. 

The  model  is  intended  to  apply  to  systems  as  diverse  as  autonomous  robots, 
knowbots  -  and  thermostats.  The  agent  may  have  a  physical  presence  or  just  exist 
within  the  memory  of  a  computer.  The  control  component  could  be  implemented  in 
software  or  hardware.  By  refining  this  abstract  model,  particular  classes  of  agents 
can  be  specified. 

This  formal  specification  first  defines  the  basic  data  types;  an  environment,  a 
task  and  an  agent.  These  components  are  then  used  to  define  the  general  agent 
system  and  a  deliberative  agent  system.  Binary  definitions  of  the  agent  properties 
are  given  in  terms  of  these  agent  systems.  Following  this,  a  utility  function  is 
defined  over  possible  task  completions.  This  allows  the  agent  properties  to  be 
refined  and  stated  as  partial  orders.  When  a  probability  distribution  over  the 
possible  initial  states  is  added,  expected  performance  of  an  agent  can  be  defined. 
Using  expected  performance,  agent  properties  tu'e  further  refined. 

The  formal  aspects  of  our  definitions  are  presented  using  the  Z  specification 
language  [Spivey,  19891.  A  short  introduction  to  the  language  is  given  in  appendix 
A.  The  specification  consists  of  a  prose  description  and  Z  code.  These  two 
components  complement  each  other.  The  prose  explains  the  specification  in  an 
intuitive  way  and  gives  the  intentional  meaning  of  the  Z  code.  The  Z  code 
provides  precise  definitions  in  a  language  with  well  defined  semantics.  Developing 
the  specification  is  a  process  of  creating  and  refining  both  the  text  and  the  Z  code. 
The  Z  code  is  created  based  on  the  written  description.  The  process  of  writing 
the  Z  code  often  identifies  inconsistencies  and  omissions  in  the  original  text.  In 
addition,  the  Z  code  can  be  put  through  a  syntax  and  type  checker  to  identify  more 
subtle  errors.  Updating  the  prose  to  conform  to  the  revised  Z  code  often  highlights 
assumptions  and  implications  that  can  be  used  to  further  refine  the  prose  and  the  Z 
code. 

It  is  intended  that  the  basic  idea  behind  each  definition  presented  in  this  report 
should  be  understandable  from  the  text  alone,  though  not  in  full  detail. 

'A  knowbot  is  an  agent  that  exists  as  a  program  running  on  a  computer  or  computer  network.  It 
performs  tasks  such  as  information  retneval  from  databases. 
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Primitive  Data  Types 


In  this  section,  the  primitive  data  types  used  to  describe  agents,  environments  and 
tasks  are  presented  and  discussed.  These  data  types  are  used  to  describe  the  state 
of  each  component  and  to  describe  interactions  between  components.  In  addition, 
we  define  the  term  Chronicle  which  is  used  to  represent  how  components  of  the 
agent  and  environment  change  over  time. 

External  Descriptions 

The  externally  observable  state  consists  of  the  state  of  the  environment  and  the 
externally  observable  state  of  the  agent.  Each  is  described  by  a  primitive  data  type. 

[  WORLD.  CONFIGURATIO.X] 

A  WORLD  is  a  complete,  instantaneous  description  of  the  environment.  It 
includes  the  state  of  the  environment  as  well  the  instantaneous  rates  of  change  of 
that  state.  It  is  like  a  very  detailed  snapshot  of  the  environment. 

A  CONFIGURATICN  refers  both  to  the  composition  of  the  agent’s  “body”  and 
its  current  position.  For  instance,  a  CONFIGURATION  specifies  how  many  arms 
the  agent  has  and  the  position  of  each  arm.  Like  a  WORLD,  a  CONFIGURATION 
is  an  instantaneous  description  that  includes  the  instantaneous  rates  of  change  of 
the  state. 

A  complete  description  of  the  external  state  of  a  system  requires  both  a  WORLD 
and  a  CONFIGURATION.  An  ExtemalState  is  such  a  description.  It  is  interesting 
to  note  that  not  all  combinations  of  WORLDS  and  CONFIGURATIONS  may  be 
possible.  The  physical  laws  of  the  environment  may  restrict  which  pairs  are  legal. 
For  example,  two  things  cannot  be  in  the  same  place  at  the  same  time.  Each 
environment  will  determine  which  ExtemalStates  are  possible. 

_ Fxl(  ninlSlatt  - 
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It  is  impossible  to  completely  specify  the  external  state  of  the  system  in  exact 
detail.  From  a  practical  standpoint,  some  of  the  details  must  necessarily  be  omitted. 
It  is  also  desirable  to  abstract  away  irrelevant  details.  An  abstract  description  of 
the  external  state  can  be  represented  by  the  set  of  ExtemalStates  that  are  consistent 
with  the  partial  description.  A  predicate  such  as  OniA.B)  is  equivalent  to  the  set  of 
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ExtemalStates  where  the  predicate  holds.  An  ExtemalDescnption  is  defined  to  be 
a  set  of  ExtemalStates  representing  an  abstract  description  of  the  external  state. 

ExternalDescription  ==  P  ExternalSlate 

Internal  State 

The  controller  within  the  agent  may  maintain  some  information  in  its  memory.  A 
STATE  is  defined  to  be  a  complete  description  of  the  internal  state  of  the  agent’s 
controller.  It  represents  the  contents  of  the  agent’s  memory.  Note  that  since  it  is  a 
primitive  data  type,  nothing  is  said  about  the  structure,  capacity  or  organization  of 
this  memory. 

[STATE] 

Commands  and  Interactions 

Interactions  between  the  agent’s  controller  and  its  effectors  and  between  the  agent’s 
effectors  and  the  environment  are  mediated  by  COMMANDS  and  INTERAC¬ 
TIONS,  respectively. 

[COMMAND.  INTERACTION] 

A  COMMAND  is  a  signal  that  the  agent’s  control  component  can  send  to  the 
agent’s  mechanism.  The  results  of  sending  a  particular  COMMAND  signal  will 
depend  on  the  CONFIGURATION  of  the  Mechanism  and  WORLD  in  which  it  is 
sent.  A  COMMAND  used  in  this  sense  is  not  the  same  as  what  is  meant  by  an 
action  in  classical  Artificial  Intelligence  planning.  A  COMMAND  is  not  a  high 
level  action  like  putOn(A,B).  It  is  more  like  a  setting  of  the  switches  that  control 
the  agent.  A  single  configuration  of  the  switches  may  cause  the  robot  to  begin 
moving  forward  and  open  its  gripper. 

To  get  a  better  idea  of  what  aCOMMAND  is,  imagine  yourself  as  the  controller 
inside  the  agent.  In  front  of  you  is  a  control  panel  with  some  buttons.  You 
control  the  agent  by  pushing  combinations  of  these  buttons.  Each  COMMAND 
corresponds  to  one  combination  of  buttons  you  could  push. 

An  INTERACTION  is  the  influence  the  Mechanism  exerts  on  the  environment 
as  the  result  of  acting  on  a  particular  COMMAND  signal.  The  exact  INTERAC¬ 
TION  depends  on  the  Mechanism,  the  COMMAND  signal  and  the  CONFIGURA¬ 
TION  of  the  Mechanism. 

The  advantage  of  having  separate  COMMANDS  and  INTERACTIONS  is  that 
it  allows  for  the  distinction  between  the  signals  sent  to  the  mechanism  and  the 
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effects  the  mechanism  has  on  the  environment.  A  COMMAND  that  turns  on  the 
arm  lifting  motor  will  produce  a  different  INTERACTION  depending  whether  the 
motor  fuse  is  burnt  out  or  not.  There  can  also  be  more  than  one  way  of  achieving 
the  same  INTERACTION.  I  can  push  a  block  with  my  right  hand  or  my  left  hand. 
The  effect  on  the  block  is  the  same,  as  long  as  the  force  applied  is  the  same. 

Perception 

An  agent  receives  information  about  the  state  of  the  environment  through  its 
sensors.  A  PERCEPT  is  a  signal  that  the  agent’s  sensors  pass  to  the  agent’s  control 
component.  It  is  the  input  counterpart  to  a  COMMAND.  The  PERCEPT  sent 
can  be  influenced  both  by  the  WORLD  and  the  CONRCURATION  of  the  agent’s 
mechanism.  For  instance,  the  output  of  a  camera  will  depend  on  the  state  of  the 
world  and  the  direction  the  camera  is  pointed  in.  Again  imagine  yourself  as  the 
controller  inside  the  agent.  The  control  panel  has  some  lights  on  it  indicating  the 
current  value  of  the  sensor  readings.  These  lights  provide  your  only  access  to 
the  information  about  the  outside  world.  Each  of  the  possible  patterns  of  lights 
corresponds  to  a  single  PERCEPT. 

[PERCEPT] 

A  PERCEPT  encodes  the  output  of  ail  the  sensors  in  a  single  value.  When 
designing  a  particular  agent,  it  may  be  helpful  to  distinguish  the  output  from  each 
.sensor  and  to  identify  the  possible  values.  A  complete  specification  of  sensor  output 
would  then  consist  of  the  value  of  the  output  for  each  sensor.  When  considering 
agents  in  the  abstract,  it  is  desirable  to  hide  details  about  the  number  of  sensors  and 
the  values  they  can  return.  Combining  the  individual  values  into  a  single  composite 
value  does  not  reduce  the  amount  of  information  obtained  from  the  sensors.  The 
reason  for  having  a  single  composite  value  is  to  make  definition.^  dealing  with 
sensor  output  simpler. 

Time  and  Chronicles 

In  this  specification.  Time  is  measured  in  discrete  intervals.  For  convenience,  we 
mapped  each  interval  to  an  integer,  to  k,  ;p  track  of  the  sequencing.  A  discrete 
time  representation  was  chosen  since  it  results  in  cleaner  property  definitions  with 
little  loss  in  generality.  This  specification  does  not  depend  on  the  size  of  the 
time  interval.  Nowhere  is  the  time  quanta  specified.  By  making  the  time  quanta 
sufficiently  short,  continuous  time  can  be  approximated  to  any  desired  granularity. 
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rinu  ——2. 

The  evolution  of  ;in  entity,  either  a  component  or  an  interaction,  over  an 
interval  of  time,  can  be  represented  using  a  Chronicle  (McDermott.  198/1.  In 
our  representation,  a  Chronicle  consists  of  a  series  of  samples  of  the  entity.  Each 
sample  represents  the  value  of  the  entity  at  the  start  of  a  time  interval.  Chronicies 
are  well  suited  for  modeling  entities  that  change  only  at  discrete  times.  A  good 
e.xample  of  such  a  entity  would  be  the  output  of  a  controller  implemented  using  a 
micro-processor.  The  controller’s  outputs  would  only  change  synchronously  with 
the  micro-processor’s  clock.  For  a  continuously  varying  entity,  a  chronicle  is  only 
an  approximate  representation  in  the  same  way  that  the  samples  on  an  audio  CD 
only  approximate  the  original  music.  The  critical  factor  in  such  an  approximation 
is  the  sampling  rate.  The  entity  must  be  sampled  often  enough  to  prevent  any 
required  information  from  being  lost. 

Formally,  a  Chronicle  is  defined  to  be  a  partial  function  that  maps  times  to  cor¬ 
responding  values.  All  Chronicles  have  definite  start  times.  In  addition,  we  define 
FiniteChronicles  to  have  finite  end  times  as  well.  The  definitions  of  Chronicle  and 
FiniteChronicle  are  parameterized  by  the  type  of  entity,  Q.  A  particular  kind  of 
Chronicle  is  defined  by  specifying  the  type  of  entity.  For  example,  a  Chronicle  of 
external  states  would  be  "Chronicle(Extema!State|”. 

('}ir(}t\icU\Q\  ==  {r  ;  linn  -t-  Q  (  3 /(>  ;  I'nnt  •  dom  <•  =  {/|  :  hux  |  h  j  Ai 


FiniteChwnicle[Q]  ==  {o  ;  Time  -+—  Q  \  3  t\.i2  :  Timi  •  dom  12} 

Here  we  define  six  auxiliary  functions  for  dealing  with  chronicles.  They  will  be 
used  to  make  forniulas  involving  chronicles  more  concise  and  readable.  The  name 
of  each  function  is  meant  to  suggest  its  semantics.  The  timesOf  function  returns  the 
set  of  times  covered  by  the  chronicle,  while  the  startOf  function  returns  the  earliest 
time.  For  inductive  definitions,  it  is  convenient  to  be  able  to  refer  to  the  times 
covered  by  the  chronicle,  after  the  initial  state.  The  rcstTimesOf  function  returns 
the  times  covered  by  the  chronicle,  minus  the  star!  time.  It  is  also  useful  to  be  able 
to  refer  to  the  range  of  values  covered  in  the  chronicle.  The  valuesOf  function 
returns  the  set  of  values  for  the  quantity  in  the  chronicle  and  the  firstOf  function 
returns  the  initial  value.  Finally,  the  pretixesOf  function  returns  all  chronicles 
which  are  prefixes  of  the  gi  /en  chronicle. 
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MQ] 

timesOf  :  Chronicle[Q]  —  P  Time 
startOf  :  Chmnirle[Q\ — •  Time 
restTimesOf  ;  Chronicle[Q\  —  P  Time 
valuesOf  :  Chronicle[Q\  —  P  Q 
firstOf  :  Clironirle[Q]  —  Q 

prefixesOf  :  Chmnirle[Q]  —  P  FiniteClimnicle[Q] 

V  c  :  ChivniclelQ]  • 

timesOf(c)  =  dom  r  A 

StartOf  {c)  =  min{dom  c)  A 

restTimesOf (r]  =  timesOf{c)  \  {startOf (c)]  A 

raluesOfic)  =  ran  c  A 

firstOf(r)  =  r(sturtOf(r))  A 

preJiresOfir]  —  [prefix  :  FiniteClimnirle[0]  | 

startOf  (prefix)  =  startOf  (r)  A  prefix  C  r} 


Environment 

Every  agent  operates  in  an  en\  ironment.  To  describe  an  environment,  we  must 
characterize  the  valid  states  and  how  they  change  over  time.  In  general,  the  state 
of  an  environment  is  dynamic,  changing  of  its  own  accord  and  in  response  to 
interaction  with  the  agent.  In  a  deterministic  environment,  knowing  the  exact 
state,  the  interaction  with  the  agent  and  the  “laws  of  nature"  allows  the  immediate 
future  to  be  predicted  exactly.  In  a  non-deterministic  environment,  the  best  that  can 
be  done  is  to  predict  a  set  of  possible  future  states.  Any  model  of  the  environment 
must  be  able  to  account  for  both  deterministic  and  non-deterministic  state  changes. 

In  this  framework,  changes  in  the  state  of  the  environment  will  be  represented 
as  a  Chronicle  of  the  external  state.  To  characterize  how  the  environment  changes, 
we  need  only  be  able  to  predict  the  next  state  given  the  current  state  and  the  current 
interaction  with  the  agent.  This  can  be  done  if  the  Markov  property  holds.  Such 
is  the  case  if  the  state  description  of  the  environment  captures  all  relevant  the 
features.  For  example,  to  predict  the  flight  of  a  ball  thrown  into  the  air,  the  state 
description  needs  to  include  the  velocity  of  the  ball  as  well  as  its  position.  The 
definition  of  WORLD  and  CONFIGURATION  include  the  state  and  instantaneous 
rates  of  change  of  state  so  that  the  Markov  property  holds  for  an  ExtemalState. 

Even  with  the  Markov  property,  it  is  not  possible  to  predict  the  next  state  for 
a  non-deterministic  environment.  The  best  that  can  be  done  is  to  predict  the  set 
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of  possible  next  states  and  the  probability  of  each  one.  When  considering  how  to 
model  non-determinism,  there  are  a  couple  of  issues  to  keep  in  mind.  For  one,  the 
model  should  allow  for  a  probability  distribution  over  successor  states.  Secondly, 
the  model  should  also  allow  the  performance  of  agents  to  be  compared  under  the 
same  conditions. 

The  approach  we  will  take  is  to  model  non-deterministic  environments  as 
deterministic  environments  with  hidden  state  variables.  To  get  an  idea  of  how  this 
works,  imagine  that  at  the  beginning  of  time  you  ask  an  all  knowing  oracle  to  write 
down  the  outcome  of  all  future  non-deterministic  events.  You  then  include  this 
information  in  the  state  of  the  environment.  Of  course,  there  can  be  no  way  that 
an  agent  could  perceive  this  information.  It  must  remain  hidden  until  each  non- 
deterministic  event  takes  place  and  the  outcome  is  revealed.  There  are  advantages 
to  modeling  non-determinism  in  this  way.  It  allows  agents  to  be  compared  under 
identical  conditions.  How  does  each  agent  do  if  the  coin  flip  comes  up  heads? 
Such  an  encoding  also  allows  a  single  probability  distribution  over  initial  states  to 
account  for  the  likelihood  of  each  state  and  the  probability  of  each  non-deterministic 
event.  In  practical  terms,  being  able  to  determine  the  next  state  rather  than  a  set  of 
possible  next  states  simplifies  the  specification  without  loss  of  generality. 

The  environment  is  represented  by  a  schema  that  embodies  the  “laws  of  Na¬ 
ture.”  The  schema  includes  a  description  of  the  valid  combinations  of  WORLDs 
and  CONFIGURATIONS,  a  function  for  specifying  how  things  change  over  time 
and  a  partitioning  of  external  states  for  hiding  non-deterministic  outcomes.  As 
described  previously,  not  all  combinations  of  WORLDs  and  CONFIGURATIONS 
are  compatible.  The  “consistent”  .set  gives  the  set  of  legal  pairs.  The  consequence 
function  maps  the  current  ExtemalState  and  the  current  INTERACTION  with  the 
agent  to  the  next  ExtemalState.  The  consequence  function  is  defined  for  all  IN¬ 
TERACTIONS  and  all  consistent  ExtemalStates.  The  resulting  ExtemalState  is 
always  a  consistent  ExtemalState. 

It  is  not  possible  for  an  agent  or  an  observer  to  determine  the  value  of  the 
hidden  state  variables.  If  it  were,  then  the  environment  would  be  deterministic.  The 
environment  schema  divides  the  set  of  world  states  up  into  sets  of  indistinguishable 
states  that  differ  only  in  the  value  of  hidden  state  variables.  This  partitioning  will 
be  used  to  enforce  the  restriction  that  hidden  state  remain  hidden.  An  agent  will 
be  restricted  to  be  able  to.  at  best,  determine  which  set  of  indistinguishable  states 
It  is  in.  A  task  specification  must  also  not  depend  on  the  hidden  state,  in  the  same 
way  that  it  cannot  depend  on  the  internal  state  of  the  agent. 
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_ Environment _ 

consistent  :  Exte rnnlDescription 

consequence  :  { ExternalState  x  INTERACTION )  -+~  ExternalStnte 
indistinguishable  :  P  ExternalDescription 

[ran  consequence)  C  consistent 

dom(dom  )  C  consistent 

U  indistinguishable  =  consistent 

'i  a,  b  \  indistinguishable  •anbj^0<:i-a  =  b 


To  assist  in  enforcing  the  restriction  on  indistinguishable  states,  we  define  a 
function  that  takes  an  environment  and  returns  the  set  of  pairs  of  indistinguishable 
states.  The  returned  set  consists  of  all  pairs  of  ExtemalStates  that  differ  only  in 
their  hidden  state. 

same  ExtemalStates  :  Environment  —  P(  ExternalStnte  x  ExternalState  ) 

V  env  :  Environment',  f  •  ExternalState  • 

€  same  Exte  rnalStates(  env) 

O  (3  ind  :  env. indistinguishable:  •  fi  €  ind  A  G  ind) 

External  Chronicle 

An  ExtemalChronicIe  is  a  Chronicle  of  the  ExternalState.  It  describes  the  evolution 
of  the  environment  and  the  behaviour  of  the  agent. 

Exte rnalChronick  ==  FiniteChronicle\ExlernalSlale  ] 

In  a  particular  environment,  only  some  Chronicles  are  possible.  To  be  valid, 
the  sequence  of  ExtemalStates  must  be  consistent  and  follow  the  “laws  of  nature," 
that  is,  they  must  result  from  repeated  application  of  the  consequence  function. 
The  Chronicles  function  returns  the  valid  ExtemalChronicles  for  a  particular  envi¬ 
ronment. 
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chronicles  ;  Eiicironment  — •  P  EiternalChronicle 


V  mv  ;  Environment  • 
chronicles(  env) 

=  {chronicle  :  ExternalC'hronicle  | 

{vaiuesOfichmnicle)  C  etiv. consistent)  A 

(V  t  :  rest  TimesOf  (chronicle)  •  3  intemction  :  l.\TERA(  'J  IO.\  • 

{env.conse(juetice(chirmiclt  (t  —  \  ).  interaction)  =  chronirlt  [  t )))} 

Two  Chronicles  are  indistinguishable  if  they  cover  the  same  time  period  and 
each  of  the  external  states  in  the  Chronicle  are  indistinguishable.  “safneChronicles” 
is  a  function  that  takes  an  environment  as  input  and  returns  the  set  of  pairs  of 
indistinguishable  Chronicles. 

snnieC'hronicles  :  Envimnnient  —  P{  ExternalChmnich  \  Ext(  rnoK  'hmnirh  ) 

Vci,('2  :  External('hronicle\  env  :  Envimnnient  • 

(''1-^2)  €  smneC’hronicles(env) 

O  tiniesOf(C])  =  timesOf(c2)  A 
('^  t  :  timesOf(c\)  • 

3  irul  :  env. indistinguishable  •  c^l)  €  ind  A  r'2(  0  €  ii>d) 


Task 

A  task  is  a  description  of  what  the  agent  is  supposed  to  achieve  in  the  Environment. 
There  are  a  wide  variety  of  possible  tasks.  These  include  classic  blocks  world 
problems  as  well  as  tasks  with  time  constraints  and  tasks  of  maintenance.  The 
method  of  specifying  tasks  must  be  able  to  encode  each  of  these  types  of  tasks. 
In  addition,  the  task  specification  should  allow  for  different  types  of  performance 
evaluation. 

All  task  specifications  require  the  environment,  the  set  of  possible  initial  con¬ 
ditions  and  a  method  for  evaluating  performance.  The  task  schema  provides  the 
basic  structure  used  to  define  all  types  of  tasks.  The  schema  requires  that  the 
initial  ExtemalDescription  be  consistent.  The  method  of  evaluation  is  given  as  a 
parameter,  “E”  to  allow  the  .schema  to  be  specialized  for  different  types  of  task 
evaluation  functions.  Throughout  this  specification,  the  “E"  parameter  will  refer 
to  the  method  of  task  evaluation. 
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Task[E] _ 

environment  :  Envimnnient 
initialConditions  :  ExteninlDescription 
evaluation  :  E 

V  u’  ;  initialConditions  •  w  €  environment. consistent 


The  simplest  form  of  task  evaluation  is  binary.  Either  the  task  is  accomplished 
or  it  is  not.  Such  an  evaluation  can  be  encoded  by  listing  ail  of  the  ways  of  accom¬ 
plishing  the  task.  An  agent  is  successful  if  its  behaviour,  in  response  to  conditions 
in  the  environment,  is  one  of  the  methods  of  accomplishing  the  task.  Note  that  we 
are  not  suggesting  that  any  implementation  would  use  such  a  representation.  It  is 
only  meant  to  serve  as  a  useful  conceptualization. 

A  BinaryEvaluation  is  defined  to  be  the  set  of  desired  ExtemalChronicles 
that  gives  all  the  ways  that  the  task  can  be  accomplished.  The  BinaryEvaluation 
schema  is  used  as  a  parameter  to  the  task  schema  to  define  a  BinaryTask.  The 
Binary  Task  schema  imposes  further  restrictions  on  the  desired  Chronicles.  The 
desired  Chronicles  must  be  valid  Chronicles  for  the  environment.  In  addition,  each 
Chronicle  must  start  in  one  of  the  given  initial  states.  Finally,  the  task  evaluation 
is  not  allowed  to  differentiate  between  Chronicles  that  differ  only  in  hidden  state. 

_ BinaryEvaluation _ 

desired  :  P  ExternalChronicle 


_ BinaryTask _ 

Tnsk[Binary  Evaluation] 


evnluntii  ..desired  C  chroniclcs(enviwnme  nt) 


V  r  :  freilueition.de ■•yiird  •  JirstOf{r)  £  initieiK 'onditions  A 
(Vf'  :  Exle  rnedChi'onltde  • 

{c.c']  G  same  ('hroniede  s(<  iirire>nme  nt )  =>  <■'  G  e  ralualiiin.de  siird) 


The  following  examples  illustrate  the  generality  of  the  task  representation. 
The  examples  include  tasks  of  achievement,  tasks  of  maintenance  and  tasks  of 
information  gathering. 

Tasks  of  achievement  require  the  agent  to  achieve  some  condition  in  the  world. 
Classic  STRIPS  tasks  are  tasks  of  achievement  where  the  conditions  to  be  achieved 
are  stated  as  a  prepositional  goals  iFikes  and  Nilsson,  19711.  Such  a  task  is 
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represented  by  the  set  of  Chronicles  where  the  goals  are  eventually  achieved.  The 
desired  set  of  Chronicles  for  the  blocks  world  task  On'A.B)  would  include  all 
Chronicles  that  started  in  one  of  the  initial  states  and  end  with  block  A  on  block  B. 
Note  that  this  type  of  task  requires  an  infinite  number  of  desired  Chronicles  since 
no  time  limit  is  specified.  Any  Chronicle  where  the  goal  is  eventually  achieved 
is  allowed.  Tasks  that  involve  temporal  constraints  restrict  the  number  of  desired 
Chronicles.  The  task  On(A,B)  by  5:00  pm  today  restricts  the  desired  Chronicles  to 
those  that  achieve  the  goal  by  the  deadline. 

A  task  of  maintenance  is  a  task  where  the  agent  must  maintain  some  condition 
in  the  environment.  For  example,  a  thermostat  agent  may  have  to  maintain  the 
temperature  of  the  room  between  20  and  22  degrees  Celsius.  The  task  is  represented 
by  mapping  the  initial  state  to  the  set  of  Chronicles  where  the  temperature  does  not 
vary  outside  of  the  allowed  limits,  ft  is  also  possible  to  add  temporal  con‘^traints 
such  as  “Don’t  let  the  temperature  vary  above  22  degrees  for  more  than  3  minutes 
at  a  time.” 

Tasks  of  observation  require  the  agent  to  determine  some  information  about 
the  state  of  the  world  and  act  on  it.  Since  tasks  are  behavioural  descriptions,  tasks 
must  be  specified  in  terms  of  behaviour;  they  cannot  specify  anything  about  the 
mental  state  of  the  agent.  For  example,  the  task  to  “Go  outside  and  see  if  it  is 
raining”  is  not  operational.  There  is  no  way  to  determine  if  the  agent  “knows” 
whether  it  is  raining.  We  cannot  infer  that  the  agent  would  know  if  it  was  raining 
even  if  we  observed  the  agent  going  outside.  Such  a  task  can  be  made  operational 
by  adding  actions  that  depend  on  the  observations.  The  example  could  be  changed 
to  :  “Go  outside  and  open  your  umbrella  if  it  is  raining.” 

When  defining  a  task,  one  must  be  careful  when  dealing  with  tasks  that  don’t 
have  a  deadline  or  other  constraints  that  prevent  infinite  loops.  Consider  again 
the  blocks  world.  In  most  formulations  of  planning  problems  for  this  domain, 
there  is  no  time  limit  on  how  long  the  .  'ac  it  may  take  to  complete  the  task.  As 
stated  before,  such  a  task  results  in  an  infinite  set  of  des’red  Chronicles.  An  agent 
that  does  nothing  will  always  be  in  a  desired  state,  but  will  never  achieve  the 
goal.  Even  if  the  agent  were  to  act.  determining  whether  it  will  ever  achieve  the 
goal  is  an  undecidable  problem  I  Chapman,  19871.  An  analogy  can  be  made  with 
the  difference  between  partial  and  total  correctness  for  a  computer  program.  A 
program  is  partially  correct  if  it  never  outputs  a  bad  result  and  is  totally  correct 
if  it  iiever  outputs  a  bad  result,  but  always  outputs  a  result  and  stops.  Similarly, 
an  agent  is  partially  successful  if  it  never  does  anything  wrong,  but  is  only  totally 
successful  if  it  also  eventually  completes  the  task.  In  this  specification,  success 
will  mean  total  success. 
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Agent 


An  agent  is  any  entity  created  to  accomplish  a  task.  We  distinguish  the  agent 
from  the  environment  to  enable  us  to  substitute  one  agent  for  another  in  order 
to  compare  their  performance.  Within  the  agent,  we  distinguish  the  mechanism 
from  the  contr  )ller,  again  to  allow  comparisons  between  different  mechanisms  and 
controllers. 

Mechanism 

An  agent’s  Mechanism  determines  how  the  agent  can  perceive  and  affect  its  envi¬ 
ronment.  It  provides  the  agent’s  only  means  for  interacting  with  the  environment. 
The  mechanism’s  sensors  provide  information  about  the  state  of  the  WORLD  and 
the  mechanism’s  effectors  provide  a  means  for  changing  the  WORLD.  The  dis¬ 
tinction  between  sensors  and  effectors  has  more  to  do  with  the  flow  of  information 
and  influence  rather  than  physical  arrangement.  A  force  sensor  on  the  end  of  an 
arm  may  be  both  the  point  of  contact  that  affects  the  environment  as  well  as  the 
supplier  of  information  about  the  magnitude  of  the  force. 

A  mechanism  is  represented  by  a  pair  of  functions  that  model  its  sensors 
and  its  effectors.  The  perceive  function  models  sensors  by  mapping  the  current 
ExtemalState  to  a  PERCEPT.  The  effects  function  represents  the  effectors  as  a 
mapping  from  a  COMMAND,  issued  by  the  agent’s  controller,  and  the  agent's 
current  CONFIGURATION  to  an  INTERACTION  with  the  environment.  The 
perceive  mapping  allows  foe  perceptual  aliasing  and  sensor  noise.  Perceptual 
aliasing  results  when  more  than  one  distinguishable  ExtemalState  maps  onto  the 
same  PERCEPT.  Sensor  noise  is  the  result  of  non-deteiministic  mapping  of  a  single 
world  onto  multiple  PERCEPTs.  Noise  is  modeled  by  using  the  hidden  world  state 
to  map  indistinguishable  ExtemalStates  to  different  PERCEPTs. 

_ Mechanism _ 

perceive  :  ExternalStat(  RPJRCLP T 

effects  -.(COMMAND  x  CONFIC.UR  .\TION )  ^  INTER  ACTION 


The  following  functions  characterize  the  mechanism’s  interaction  with  the 
controller.  The  mechPercepts  function  gives  the  range  of  PERCEPTs  that  the 
mechanism’s  sensors  can  generate.  Similarly,  the  mechCommands  function  gives 
the  range  of  COMMANDS  that  the  mechanism  can  accept.  These  functions  will 
be  used  to  simplify  definitions  involving  the  mechanism. 
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niechPercepts  :  Mechanism  —  P  PERCEPT 
mechCommands  :  Mechanism  —  P  COMMAND 

V  Mechanism  • 

mechPercepts(6 Mechanism)  =  ran  perceive  A 
mechCommands(0  Mechanism)  =  dom(  dom  ) 

Controller 

In  the  abstract,  the  internals  of  an  agent  can  be  modeled  as  a  finite  state  controller 
that  consists  of  a  control  function  and  a  memory.  The  control  function  is  a  mapping 
from  a  PERCEPT  and  current  STATE  to  a  COMMAND  and  next  STATE.  The 
exact  nature  of  the  control  mapping  and  the  information  encoded  in  the  state  are 
determined  by  the  agent’s  architecture  and  implementation. 

The  controller  schema  defines  a  controller  to  be  a  generic  partial  function 
where  the  type  of  the  state  is  given  as  a  parameter,  “5”.  This  allows  controllers 
with  different  memory  organizations  to  be  specified  as  specializations  of  a  generic 
controller.  Throughout  this  specification,  the  “5”  parameter  will  refer  to  the 
organization  of  the  agent’s  memory.  As  a  sanity  constraint,  the  control  function  is 
limited  to  never  produce  a  state  that  it  cannot  accept  as  input. 

f=[5]-  - -  -  - 

Controller  :  P({  PERCEPT  x  5)  ^  ( COMMAND  x  .S')) 

V  ctr  :  Controller  •  (ranfran  ctr))  =  ( ran( dom  c/r ) ) 


Below,  a  set  of  helper  functions  are  defined  to  extract  information  about  a 
controller.  The  ctrStates  of  a  Controller  are  the  set  of  possible  controller  STATEs. 
The  ctrCommands  of  a  controller  are  the  set  of  commands  the  controller  can  issue. 
Finally,  the  ctrPercepts  of  a  controller  are  the  PERCEPTs  that  the  controller  can 
accept  as  input. 

p  [.S] - - ^  ...  -  - 

rtrStafes  ;  Controlh  r[S]  —  P  .S' 

rtrP(  rcf  pis  :  Control h  r[S]  —  P  PLR(  EPT 

ctrCommands  ;  Conlmller[S]  —  P  COMMAND 

V  ctr  :  Controlltr[S]  • 

rtrStntes(ctr)  —  ran(domr/r)  A 
ctrPercepts(ctr)  =  dom(dom  ctr)  A 
firCommnrids(rtr)  =  dom(ran  ctr) 
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A  complete  agent  consists  of  a  mechanism,  a  controller  and  an  initial  internal 
state.  The  controller  and  the  mechanism  must  be  matched  in  terms  of  PERCEPTs 
and  commands;  That  is,  the  controller  must  be  able  to  accept  the  PERCEPTs 
generated  by  the  mechanism  and  the  mechanism  must  be  able  to  handle  the  COM¬ 
MANDS  issued  by  the  controller.  The  agent  schema  also  includes  an  initial  state  for 
the  controller.  This  initial  state  encodes  any  explicit,  a  priori  knowledge  that  the  de¬ 
signer  has  given  the  agent.  Different  types  of  agents  are  defined  as  specializations 
of  this  general  agent  model. 

_ - 

controller  :  Control ler[S\ 
mechanism  :  Mechanism 
initiallnternalStale  :  5 

ctrCommands(  controlle r)  C  mechCoinmnnds{  nif  chanism) 
mechPercepts(  mechanism)  C  ctrPerceptsl  coni  roller) 
initiallnternalState  €  ctrStates{  controller) 


Agent  System 

Putting  the  parts  together,  we  get  an  agent  system  consisting  of  the  agent  and  the 
task  that  the  agent  is  to  perform.  The  agent  is  parameterized  by  the  organization  of 
its  internal  state  and  the  task  is  parameterized  by  the  type  of  evaluation  function. 

_ AgentSystem[S .  E] _ 

■4(7fnf[5] 

Tnsk[E] 


Agent  Chronicles 

Now  that  the  basic  framework  has  been  defined,  we  describe  the  machinery  needed 
to  characterize  how  the  agent  and  the  environment  interact  and  evolve  over  time. 
The  final  result  will  be  a  function  that  takes  an  agent  system  and  an  initial  state 
and  returns  the  chronicle  of  external  state.  This  function  will  form  the  basis  for 
defining  successful  and  in  turn  other  agent  properties. 

The  details  of  how  the  system  changes  with  time  are  somewhat  complex,  but 
the  basic  idea  is  simple.  Given  a  complete  description  of  the  AgentSystem  and  its 
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state,  the  state  at  the  next  time  interval  can  be  determined.  The  future  Chronicle  of 
the  system  state  is  generated  by  repeatedly  determining  the  next  state.  The  part  of 
the  agent  Chronicle  that  is  of  interest  is  the  external  state,  since  it  is  the  observable 
behaviour  of  the  agent.  The  ExtemalChronicle  can  be  obtained  by  projecting  the 
external  state  out  of  the  Chronicle  of  the  system  state. 

The  AgentSystemState  schema  is  a  complete,  instantaneous  description  of  the 
agent  system.  It  consists  of  the  AgentSystem  augmented  by  the  current  internal 
and  external  states.  In  the  schema,  the  internal  and  external  states  are  restricted  to 
be  legal  values  for  the  agent  and  the  environment. 

_ i(jentSystemStnte[S.  E] - 

AgentSystemlS .  E] 
internnlSlate  :  S 
txternalStntr  :  Externals! ate 

internalState  €  rtrStates(ronlrollf  r) 

f  xternalState  €  environment .ronaistent 


A  subset  of  the  AgentSystemStates  are  possible  start  states.  An  AgentSystem- 
Start  is  an  AgentSystemState  with  the  initial  internal  state  and  one  of  the  possible 
initial  external  states. 

_ AgentSystemStartlS .  E] _ 

AgtntSystemStntf:{S ,  C] 

internalState  =  initiallnternalStatf 
f  xte  rnalState  £  initialf'onditions 


Each  transition  of  the  system  state  mu.st  be  a  valid  step  which  depends  on 
the  environments  consequence  function  and  the  agent.  The  AgentSystemStep 
transition  schema  defines  a  valid  step.  The  agent's  control  function  is  used  to 
update  the  internal  state  and  issue  a  command.  The  command  is  passed  to  the 
agent's  mechanism  and  interacts  with  the  environment  to  produce  the  next  external 
state.  The  agent  and  the  task  remain  unchanged. 
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_ AgentSystemStep[S ,  £] _ 

AAg€ntSysteinStnte[S.  f] 

3  cmd  :  COMMAND  • 

rontroller(  mechanism. perceive(fMernalStnlf  ).  internalStntf  ) 

=  (cmd.  internalSlatf' )  A 

en  inwnment  .conseqite iice(  t  xtciiialState . 

mechanism. effectsi  cmd.  externalState .configuration ) ) 

=  externalState' 

6  AgentSystem  =  6  .AgentSystem' 


As  time  proceeds,  the  external  state  and  the  agent’s  internal  state  are  updated 
after  every  time  interval.  This  is  not  to  say.  however,  that  the  controller  must 
go  through  a  decision  cycle  and  generate  a  new  COMMAND  after  each  interval. 
Likewise,  it  does  not  mean  that  the  environment  only  changes  when  the  controller 
generates  a  new  command.  The  controller  may  take  any  number  of  intervals  to 
process  the  sensor  output  and  calculate  the  next  command  to  issue.  In  the  mean 
time,  the  controller  may  continue  to  issue  the  same  COMMAND  (push  the  same 
buttons)  or  issue  a  null  command  (not  push  any  buttons).  What  happens  will  depend 
on  the  implementation  of  the  controller.  The  state  of  the  controller  is  updated  every 
interval  to  reflect  any  progress  made  in  doing  computation.  Likewi.se.  the  state  of 
the  environment  is  updated  to  reflect  any  changes.  The  critical  factor  is  the  length 
of  the  time  interval.  It  must  be  short  enough  that  no  significant  information  about 
the  external  state  is  lost. 

An  AgentChronicle  is  an  infinite  Chronicle  of  the  evolution  of  the  AgentSys- 
temState.  Each  transition  in  the  sequence  is  a  valid  step  and  the  first  state  in  the 
Chronicle  must  be  a  valid  start-state. 

AgentChmnicle[S .  E]  ==  {agi  nl( 'limnicle  :  Climnich  [Agt  nt.Systi  ni.Stati  [.S .  E]]  \ 
3  .Agfnt.Systeni.Slarl[.S.  E]  •  0  Agi  ntSyste  mStart  —  JirslOfiayt  nt(  'hronich  )  A 
(V  /  ;  rfstTimcsOf(agfnl('hronirli  )  • 

(  3  .\gt  ntSysli  inSlali  [.S'.  /•.'];  Ag<  nlSy.'^h  niSlnlf  '[.S'.  /■']  • 

6 AgentSystt  niStat(  =  agi  nl( 'hronich  ( I  —  1)  A 
d.AgentSystemState'  =  agcntChronich  (t)  A 
.AgentSystemStrj)[S.  £"]))} 

As  noted  above,  if  the  system  starts  in  a  particular  start  state,  then  the  AgentChron¬ 
icle  is  uniquely  determined.  The  AgentChronicleOf  function  maps  an  AgentSystem 
and  an  initial  ExternalState  to  an  AgentChronicle. 
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p[•^^g]  ;  -  .  ^  -  ■ 

AyentC’limniclfOf  :  (  Agf  ntSyst<ni[S,  li]  :<  Eitt  nuilStntt)  — ■  AiinitChn)niilt\S .  l.\ 

'i  AgentSystt)H[S.  fj;  Ext(  nialStatf,  agfutClimnicle  :  Agt  iil('hmnK'U[S .  t'.]  • 
AgentC'hronirleOfi  0  Agt  ntSystnn,0 ExIt  rnalSintf  )  =  agtntC  ’hronicU  => 

{3AgfntSy.stfrnSt(irfi[S.F]»ffAgfiitSyst(ntSt(irli  —  jirstOfiagt  iiK  '}in>mtli  ) 
0 Agt  ntSystt  in  =  OAgtntSysttin^  A 
[jirstUf[<rjinti'hmnu-lt  )).txif  rnalStntf  =  f) Exit  rnalStaU  ) 


When  examining  the  behaviour  of  the  agent,  we  are  only  interested  in  changes 
in  the  external  state.  The  chronicleProject  function  maps  an  AgentChronicle  to  a 
chronicle  of  the  vjxtemal  state  only.  The  chronicle  project  function  is  defined  to  be 
the  function  composition  of  the  original  chronicle  and  a  lambda  expression.  Re¬ 
member  that  a  chronicle  is  itself  a  partial  function  from  times  to  values.  The  lambda 
expression  is  a  function  mat  projects  the  ExtemalState  from  the  AgentSystemState. 
When  the  original  chronicle  is  composed  with  the  lambda  expression,  the  resulting 
partial  function  is  an  ExtemalChronicle  that  maps  times  to  ExtemalStates. 

=  [5.  E]  - 

chronicle  Project  :  Agent('limntcle[S.  E] —  ExlenialChmniiie 

'id  ;  AgtntChrr>ni<if[S .  E\\  Exit  nialSlalt  • 

chronicle  Pmjerl  {  a)  =  n  ;  (A  AgentSyste  niStnte[S .  E]  •  0  Exit  rnnlSlntt  ) 


Finally,  we  create  the  chronicleFrom  function  that  gives  the  behaviour  of  the 
system  when  started  in  a  particular  initial  state.  This  function  is  the  culmination  of 
the  effort  to  define  a  framework  for  describing  agents,  tasks  and  environment.  It 
forms  the  basis  for  defining  successful. 

The  chronicleFrom  function  is  the  functional  composition  of  the  AgentChron- 
icleOf  and  the  chronicleProject  Functions.  The  AgentChronicleOf  function  pro¬ 
duces  the  complete  agent  chronicle  and  the  chronicleProject  function  projects  out 
the  chronicle  of  the  external  state. 

chronicle  Eroin[S .  E]  =—  Agt  nt(  hroniclt  ()f[S .  /•,]  ;  chroniclt  I'roji  cl[S .  E] 


General  Agent  Properties 

This  section  defines  five  general  agent  properties;  successful,  capable,  percep¬ 
tive,  reactive  and  reflexive.  These  properties  are  relevant  for  any  type  of  agent 
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performing  a  task  with  a  binary  evaluation.  The  relationship  between  three  of 
these  properties  is  show  in  Figure  4.  An  agent  is  capable  if  its  effectors  are  able 
to  accomplish  the  task.  A  perceptive  agent  also  possesses  the  sensors  needed  to 
determine  how  to  operate  the  effectors  for  achieving  the  task.  A  successful  agent 
is  a  perceptive  agent  with  the  right  controller. 

To  assist  in  our  definitions,  we  define  the  relation  =Task  that  holds  between  two 
agent  systems  when  the  task,  and  hence,  the  environment  are  the  same. 

=  [.S’.  E]  — 

-  =Task  -  ■  AfjfutSj/stf  ni[S .  /".'j  • — •  Afff  ntSi/sti  in[S .  /•.'] 

V  A(jf  ntSijstf  rn\[S.  E]',  A<jf  itlSiisti  /»3[.V.  /•.']  • 

ffAfjf  iitSyslf  m\  =Task  0 A(jt  ntSysti  <=>  [0  l'ask'\  =  9  'Tii.'<k'2) 


Successful  Agents 

A  successful  agent  always  achieves  its  task.  Given  the  concept  of  an  AgentChron- 
icle  and  the  chronicleFrom  function  defined  in  the  previous  section,  it  is  easy  to 
define  success  for  an  agent  performing  a  binary  task.  The  chronicleFrom  function 
is  used  to  generate  the  infinite  chronicle  of  the  agent  system  when  started  in  a 
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particular  state.  The  agent  accomplishes  the  task  from  this  state  if  some  prefix  of 
the  infinite  chronicle  is  one  of  the  desired  chronicles.  The  agent  is  successful  if  it 
accomplishes  the  task  from  all  possible  initial  states. 

_ SuccfssfiilA(jentS!jstn)i[S] _ 

Afjfn  Uni[S .  BiiianjEi  alnatiou] 

V  It'  :  initialConditiDHS  • 

prefixesOf  { chroiiirle  Froniiff  AgentSystem.  «•))  fvnluation.dfsirrd  ^  0 


Capable  Agents 

Capability  reflects  the  ability  of  the  agent’s  effectors  to  achieve  a  task.  One  way  of 
demonstrating  capability  is  to  show  that  there  is  some  agent  with  the  same  effectors 
that  is  successful,  although  it  may  not  have  the  same  perception  or  control  function 
as  the  given  agent.  Capability  ignores  the  fact  that  the  given  agent  may  not  be  able 
to  perceive  the  relevant  characteristics  of  the  external  state  and  may  not  choose  the 
correct  COMMANDS. 

A  CapableAgentSystem  is  defined  as  to  be  AgentSystem  for  which  there  exists 
a  second  AgentSystem  with  the  same  task,  initial  conditions  and  effectors  (effects) 
that  is  successful.  That  is.  the  given  agent  would  be  successful  if  only  it  had  the 
nght  controller  and  perception. 

_ CapabItAgeiitSyste  nifS] _ 

AgentSystein[S ,  BinnryEvnluntion] 

3  Surrfs.sfnlAgentSystfni.'[S]  • 

d  AgfiitSystt  in  =Task  dSiirrr.ssfnlAgi  ntSystnn'  A 
nif  rhniiisin .( JJi  rts  =  iu>  rhdiii.sin' .fjjirls  A 
iiiitidlintf  nidlStdtf  =  inilidllnlfnidlSldti ' 


Perceptive  Agent 

Perceptiveness  measures  the  agent  s  ability  to  distinguish  salient  features  of  the 
environment.  What  constitutes  a  salient  feature  is  determined  by  the  task  and  the 
agent’s  mechanism.  Different  tasks  require  the  agent  to  respond  todifferent  features 
and  events  in  the  world.  For  example,  if  the  task  were  to  open  an  umbrella  when 
it  is  raining,  then  rain  is  a  salient  feature  that  must  be  responded  to.  The  agent’s 
mechanism  is  also  important.  Different  mechanisms  can  achieve  the  same  effect 
through  different  INTERACTIONS.  Since  an  agent’s  PERCEPTs  help  determine 
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its  COMMANDS  (and  hence  INTERACTIONS  with  the  world),  it  is  necessary 
to  know  the  mechanism  in  order  to  determine  which  PERCEPTs  are  salient.  For 
example,  if  the  mechanism  is  a  large  tank  and  the  task  were  to  move  from  one 
location  to  another,  then  sensing  bushes  and  rocks  would  not  be  required.  If  instead 
the  mechanism  were  smaller  and  could  get  tangled  in  bushes,  then  sensing  them 
would  be  salient. 

Alternatively,  perceptive  could  be  defined  to  depend  only  on  the  task  and  not 
on  the  agent’s  effectors.  An  agent  would  be  perceptive  if  its  perceive  function 
supplied  the  information  needed  for  some  effectors  to  achieve  the  task.  But,  what 
class  of  effectors  should  be  considered?  As  illustrated  by  the  tank  example  above, 
the  class  of  possible  effectors  will  determine  the  class  of  perceptive  agents. 

A  more  practical  argument  for  making  perceptive  depend  both  on  the  task  and 
the  mechanism  has  to  with  the  way  in  which  agents  are  generally  constructed. 
Agent  design,  especially  in  robotics,  usually  proceeds  from  the  design  of  the 
effectors  to  the  design  of  a  perception  system.  The  perception  system  is  selected  to 
provide  the  information  that  is  needed  to  control  the  effector  to  achieve  a  particular 
task  or  set  of  tasks.  Defining  perceptive  in  terms  of  the  agent’s  mechanism  focuses 
attention  on  the  appropriateness  of  the  perception  system  design  for  the  selected 
effectors. 

An  agent  is  perceptive  if  its  sensors  provide  the  information  needed  to  select 
COMMANDS  that  accomplish  the  task.  Perceptiveness  ignores  the  fact  that  the 
agent’s  controller  may  not  actually  select  COMMANDS  that  achieve  the  task.  The 
definition  of  perceptive  will  again  depend  on  the  existence  of  a  successful  agent,  this 
time  one  with  the  same  mechanism.  A  PerceptiveAgentSystem  is  an  AgentSystem 
which  has  the  same  sensors  and  effectors  as  a  SuccessfulAgentSystem. 

_ PfrrfpHi'fAgFJitStjstemlS] _ 

(  'apahlf  Af/f  ! 

3  Siit  rf  .'isfiil A(jf  • 

0 A(p  ntSiiFl(  HI  =Task  .s.'./i;/,  li/(  n/.S'//.s7<  ;//  A 

nil  rhiurisiii  =  iiii  rhiniisni'  A 
I  nil  ml  I  III  I  rniilSliih  =  mil  ml  I  nli  riml.'^ltih  ' 


Reactive  Agent 

There  has  been  wide  disagreement  on  what  the  term  reactive  means  when  applied 
to  an  agent.  The  American  Heritage  dictionary  defines  reactive  to  be  "Tending  to 
he  responsive  or  to  react  to  a  stimulus.  ’’Idict,  19851  In  AI,  a  common  definition  of 


reactive  is  responding  quickly  and  appropriately  to  changes  in  the  environment. 

When  considering  binary  task  achievement,  to  achieve  the  task  the  agent  must 
respond  sufficiently  quickly  and  appropriately  to  changes  in  the  environment.  An 
agent  that  is  successful  is  then  by  definition  sufficiently  reactive.  The  definition  of 
reactive  will  get  more  interesting  when  relative  task  achievement  is  considered. 

Reactive  .[gentSy.'ite  ni[S]  ==  .'■)itcre.'i.'<fid.[(jenlSfjsteni[S] 

Reflexive 

A  term  that  is  often  confused  with  reactive  is  reflexive.  An  agent  is  reflexive  if  it 
responds  only  to  immediate  stimulus.  Such  agents  are  also  called  stimulus-response 
agents. 

Reflexive  agents  don’t  need  to  maintain  any  memory.  The  history  of  the  agent 
plays  no  part  in  determining  its  actions  IChrisman  etal.,  1991 1\ 

To  assist  in  the  definition  of  reflexive,  we  define  a  function  that  determines  the 
minimum  nuniber  of  internal  states  needed  for  a  behaviourly  equivalent  agent. 

^[S.E]  - -  - 

nunCtrStates  :  ( .AgentSystenilS,  f])  —  N 

V  .-[gentSystein[S .  E]  • 

niinCtrStnte.s{  6.\g(  ntSysh  nt ) 

=  niin(  { n  :  I 

(3  .[gentSystein'lS,  E]  • 

6  Task  =  6  Task'  A 
inerhanisin  =  merhani.'on'  A 
(V  w  :  initinlConditions  • 

chronicle Troin((l.\gentSy.'iteni.  ir ) 

=  clironich  [■roni.{fl.\gt  nISy.'ilt  in' .  »’))  A 
n  =  { cl  rSlati  ■'<{  controller' ))))}) 


A  reflexive  agent  can  be  modeled  as  an  agent  system  that  never  changes  internal 
state.  In  this  framework,  that  corresponds  to  an  agent  with  a  single  internal  state 
and  hence  no  memory. 

_ Reflexive  Age ntSystem[S .  E] _ 

.\gentSyste  in[S .  E] 

niinCtrSlates(0.\g(  nlSysteni)  =  I 

'A’-gue.s  that  agenis  that  require  less  memors-  arc  more  reactive 
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Figure  5;  Deliberative  Agent  System 

The  agent  properties  defined  in  the  previous  section  apply  to  any  type  of  agent.  In 
this  section  we  introduce  a  type  of  agent  of  particular  interest  to  the  AI  community 
known  as  a  deliberative  agent.  A  deliberative  agent  has  an  internal  model  of  the 
world  and  uses  its  model  to  reason  about  the  effects  of  COMMANDS  in  order 
to  select  COMMANDS  that  it  predicts  will  accomplish  the  task.  Figure  5  shows 
a  conceptual  model  of  the  organization  of  a  deliberative  agent  system.  (The 
conceptual  model  of  a  generic  agent  was  shown  in  figure  3) 

An  agent’s  internal  model  of  the  environment  must  provide  certain  basic  func¬ 
tionality.  In  order  to  reason  about  the  consequences  of  COMMANDS,  the  model 
must  predict  how  COMMANDS  will  affect  the  external  state.  The  model  must 
also  be  able  to  derive  information  about  the  external  state  from  sensor  output.  The 
sensor  model  is  also  needed  to  predict  which  PERCEPTs  to  expect  in  predicted 
future  external  states.  In  addition  to  the  model,  the  agent  needs  an  estimate  of  the 
current  external  state.  It  is  from  this  estimated  external  state  that  the  agent  does 
projections  to  infer  the  consequences  of  potential  actions.  The  result  of  an  agent’s 
deliberation  process  is  a  plan  to  accomplish  the  task.  The  agent  needs  to  maintain  a 
representation  of  the  plan  to  be  able  to  issue  the  chosen  COMMANDS  at  the  correct 
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time.  The  representation  of  the  plan  also  allows  the  agent  to  further  elaborate  and 
revise  the  plan  as  new  information  is  gathered  and  more  computation  is  done. 

The  internal  state  of  a  deliberative  agent  has  six  components;  an  interpret 
relation,  a  project  relation,  an  estimatedExternalState,  a  plan,  a  task  and  some 
workingMemor^j.  The  interpret  relation  is  a  model  of  the  agent’s  sensors  and 
indicates  which  PERCEPTs  the  agent  believes  can  be  generated  from  a  given 
external  state.  The  project  relation  is  a  model  of  how  the  environment  changes 
in  response  to  a  given  COMMAND.  The  estimatedExternalState  is  the  agent’s 
current  estimate  of  the  external  state.  The  plan  is  represented  as  a  controller  within 
the  controller.  It  embodies  the  agent’s  intended  response  to  PERCEPTs  and  the 
passage  of  time.  The  agent  plans  by  extending  and  modifying  this  control  function 
[McDermott,  19921. 

Project  Relation  ==  Ej:tenialSt(t*r  a  COMMAND  ■ — ■  ExIernalStatr 


Interpret  Relation  ==  ExternalState  —  PERCEPT 

_ DelibStntelE] _ 

estimatedExternnlState  :  ExiernalDesrription 

plan  :  Controller[STATE] 

interpret  :  Interpret  Relation 

project  ;  Project  Relation 

task  : 

workinq Memory  :  STATE 


A  DeliberativeAgentSystem  is  an  AgentSystem  where  the  agent  has  a  delibera¬ 
tive  internal  state.  Reasoning  about  the  state  of  the  world  and  planning  are  modeled 
as  updates  to  the  agent’s  internal  state.  The  agent  selects  the  next  COMMAND  for 
execution  by  interpreting  its  plan.  For  consistency,  the  plan  in  the  internal  state 
is  restricted  to  only  produce  COMMANDS  that  the  mechanism  can  accept  and  to 
accept  all  PERCEPTs  that  the  mechanism  can  generate. 

_ Dt  libemtireA(jentSystcni[E] _ 

A()entSysteni[DelibSlnte[E].  E] 

V  inte  rnalStatc  :  ctrStalcs(  controller)  • 

cirCommands)  inte  rnalStatc. plan )  C  me cliCominand.s(  me  l•helnism )  A 
mechPe  re-e pts{  mechanism)  C  cIrPe  ive pis)  inte  nmlSleilt  .plan) 
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Since  the  agent’s  world  model  and  task  model  are  stored  in  its  state  (memory), 
the  agent  can  modify  them.  Learning,  in  a  deliberative  agent,  is  accomplished  by 
modifying  its  world  and  task  models.  However,  since  our  purpose  is  to  specify 
agent  properties  in  terms  of  these  models,  we  will  restrict  our  definitions  to  agents 
that  don’t  modify  their  models.  This  restriction  greatly  simplifies  the  definitions, 
but  will  have  to  be  relaxed  if  learning  agents  are  to  be  defined. 

Simple  deliberative  agents  are  agents  that  don’t  change  their  world  model  or 
task  model  in  the  course  of  completing  the  task. 

_ Simple  Deliberative  Age  ntSysteTn[E] _ 

Deliberative  AgentSyst€m[E] 

3  project  :  ProjectRelation\  interpret  :  InterpretRelation  • 

(V  internalState  ;  ctrStates(controller)  • 
internalState. project  =  project  A 
mternalState. interpret  =  interpret  A 
internalState  .task  =  9  Task) 


To  make  some  of  the  definitions  more  readable,  a  SimpleAgentSystem  is  de¬ 
fined  to  be  a  DeliverativeAgentSystem  with  a  binary  task  evaluation  function. 

_ SimpleAgentSystem _ 

Simple  Deliberative  AgentSystem[Binary  Evaluation] 


Deliberative  Properties 

A  deliberative  agent  depends  on  its  model  of  the  world  to  enable  it  to  accomplish 
its  task.  The  properties  defined  for  deliberative  agents  characterize  the  accuracy 
and  suitability  of  the  model  for  the  task  and  how  well  the  agent  uses  its  model. 
Predictiveness  characterizes  the  mooc:i's  ability  to  make  predictions  about  the 
environment.  Likewise,  interpretivencs',  .characterizes  the  model’s  ability  to  infer 
information  about  the  state  of  the  world  from  the  agent's  sensors.  Independent  of 
the  accuracy  of  the  model,  an  agent  is  rational  if  it  behaves  in  accordance  with  its 
model  of  the  world.  A  rational  agent  with  a  correct  model  is  sound. 

Predictive  Agent 

An  agent  is  predictive  if  its  model  of  the  world  allows  it  to  predict  the  results  of  its 
COMMANDS.  A  correct  prediction  relation  must  predict  all  the  possible  external 
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Figure  6:  Deliberative  Agent  Properties 


states  that  could  result,  and  not  predict  impossible  states.  In  this  ideal  case,  the 
project  function  is  the  same  as  the  mechanism’s  effects  function  composed  with 
the  environment’s  consequence  function. 

Given  an  environment  and  a  mechanism,  we  can  determine  the  correct  pro¬ 
jection  relation.  The  definition  of  this  relation  is  complicated  by  the  fact  that 
we  don’t  want  it  to  depend  on  hidden  state.  The  projection  relation  is  not  re¬ 
quired  to  be  clairvoyant.  The  relation  can  be  created  by  composing  the  effects 
and  consequence  functions  to  determine  which  extemalState  will  result  from  a 
given  initial  extemalState  and  command.  The  correct  prediction  relation  predicts 
that  any  state,  indistinguishable  from  the  initial  state,  can  produce  any  state  that  is 
indistinguishable  from  the  final  state. 
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rorrectPmjfrt  :  { E.nvimtmient  x  Mirhanistn)  ProjfrlRilutioii 


rnr  :  Em'imnmtul',  nurlianisni  :  .\fi  rlianisin  • 
coiTf  ct Pmjt(  t{  €iu\  nif  chanism) 

=  {n.  f  f2' :  rnv.ron.sistfiif,  cind  :  COMMAND  \ 

f’nv.ronuf  tjUf  nr<  ( <  | ,  iiitrfianisni.t  jj(t‘ls(  crnd.  ( <  |  ).c(>iiJi<Jiiivtioii ) ) 
(<’l,f'2)  €  saint  KxtfnialStatts{t  nr)  A 
(f'pt’i)  €  saint  pj-ttninlStali  s{r  nr) 

•  ((ei^  rind).t2)} 

A  predictive  agent  system  is  a  SimpleDeliberativeAgentSystem  that  starts  out 
with  a  correct  project  relation. 

_ PrrdictivtAgentSystein[E\ _ 

Simple  Dtlibt  rativt  Agt  ntSiisttin[E\ 

initialInU  rnalSlatt .pmji cl  —  roiTtrtProjtcl{  <  nrironnn  nt.  int  rhanisin  ) 


It  is  also  possible  for  the  agent  to  have  separate  models  of  how  the  world  works 
and  how  the  agent’s  mechanism  works.  These  individual  models  would  correspond 
to  the  effects  and  consequence  functions.  Having  separate  models  would  allow 
the  agent  to  reason  about  what  INTERACTIONS  are  required  to  produce  a  desired 
result  and  then  to  reason  about  how  to  produce  the  INTERACTION.  If  I  want  to 
move  a  block  east,  I  can  decide  to  apply  a  force  on  the  west  side.  I  can  then  think 
about  how  I  can  control  one  of  my  hands  to  apply  the  correct  force.  For  simplicity, 
the  two  models  were  be  composed  into  a  single  project  relation. 

Interpretive  Agent 

An  agent  is  interpretive  if  its  model  of  its  sensors  allows  it  to  correctly  interpret  the 
PERCEPTS  it  receives.  The  interpretation  must  be  accurate.  The  relation  should 
include  all  the  possible  ( ExternalState.PERCEPT)  pairs,  but  not  those  that  arc  not 
possible. 

As  was  done  for  the  project  function,  we  will  detinc  a  function  that  generates 
the  correct  interpret  relation.  Again  this  definition  is  complicated  by  the  fact  that 
it  should  not  depend  on  hidden  state. 
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correctinterpi'et  :  (  Ciivironnifiit  x  Mfchanism)  -t-~  InUrpirt Relation 


V  env  :  Environment',  mechanism  :  Mechanism  • 
correctInterpret(  env.  mechanism ) 

=  {ti.CT  :  env. consistent',  percept  :  PERCEPT  | 

( 1 1 .  ^2  J  €  same ExternaLStates{  env ) 

•  (c2,  mechanism . perceive { ci ))} 

_ InterpretiveAgentSystem[E] _ 

Simple  DeliberativeAg€ntSystem[E\ 

initiallnternalState.  interpret  =  correctlnterpreti  environment .  mechani.sm  ) 


Rational  Agent 

An  agent  is  rational  if  it  adopts  plans  that  it  predicts  will  succeed  over  plans 
predicted  not  to  succeed.  A  deliberative  agent  can  predict  the  future  by  repeatedly 
applying  its  project  and  interpret  relations  to  its  current  estimate  of  the  external 
state.  The  agent  can  use  this  ability  to  predict  the  future  to  simulate  the  execution 
of  its  current  plan.  If  such  a  simulation  leads  to  accomplishing  the  task,  then  the 
plan  is  predicted  to  succeed. 

To  define  a  rational  agent,  we  need  to  be  able  to  determine  the  result  of 
having  the  agent  simulate  a  plan.  The  PredictedChroniclesOf  function  takes  a 
DeliberativeAgentSystem,  an  initial  external  state  and  a  plan  returning  the  set  of 
predicted  AgentChronicles.  Note  that  the  result  is  a  set  of  Chronicles.  There  can 
be  multiple  possible  predicted  steps  for  any  given  state  because  the  agent’s  project 
and  interpret  are  relations  and  not  functions. 

The  definition  of  predicted  chronicles  will  parallel  the  definition  of  the  AgentChron¬ 
icles.  First,  a  predicted  step  will  be  defined.  A  predicted  Chronicle  will  consist 
of  a  sequence  of  predicted  steps.  The  PredictedChroniclesOf  an  agent  are  then 
defined  to  be  the  set  of  predicted  Chronicles  that  are  consistent  with  the  agent's 
world  model. 

A  predicted  step  is  a  single  predicted  transition  in  the  external  and  internal 
states. 
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_ PredictedSteplE] _ 

^AgentSysternState[DelibState[E].  E\ 

3  cmd  ••  COMMAND-,  state  :  DelibState[E]  • 
state  —  intemalState  A 

state  .plan(  state. interpret{  extemalState ),  state .  working  Memory ) 
=  (crnd.  intemalState' .working. Memory)  A 
((extemalState,  cmd),  extemalState')  €  state,  pmject 

OAgentSystem  =  d.AgentSystem' 


A  predicted  future  of  the  system  is  a  sequence  of  AgentSystemStates  where 
each  transition  between  states  is  a  predicted  step.  In  addition,  the  first  AgentState 
in  the  Chronicle  must  be  a  valid  AgentStartState. 


PredictedFuture  [  E] 

=  =  {agentChronicle  :  AgentChronicle[DelibState[E],  E\  \ 

3  .AgentSystemStart[DelibStat€[E\,  E\  • 

6  AgentSystemState  =  first  Of  (agentChronicle)  A 
(V<  :  restTimesOf (agentChronicle)  • 

(3  .\gentSy$temState[DelibState[E],  E];  .\gentSystemb(nte'[DelibStnte[E].  E] 
B .AgentSystemState  —  ngentChromcle(t  -  1 )  A 
9 .AgentSystemState'  =  agentChronicle)  t )  A 
PredictedStep[E] ) ) } 


Given  a  particular  deliberative  agent  system  and  an  initial  world  state,  it  is 
possible  to  generate  the  set  of  predicted  agent  Chronicles  that  are  consistent  with 
the  initial  conditions  and  the  agent’s  world  model.  The  PredictedChroniclesOf 
relation  maps  deliberative  agent  systems  and  initial  world  states  to  the  set  of 
AgentChronicles. 
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[^1  -  ^ . -  ■■  ^  ■—  ; 

FrfdictKlChronirU.'iOf  :  {  Df  UIm  rntivf  A(jf  ntSijstt  ni[K]  <  ('oitlrr>llt  r  x  l-.xli  nutlSldlt  i 

— ■  P  A(ji  ntC’htr>iiiil([I)t  ItbStdti  [F],  f.'] 


V  Df  libt  mtivf  Agf  ntSysteni[F]',  plan  :  ( 'ontnAU r\  Fxtt  rnal.Sfith  • 

PndicttdChronicU  x()f{  dOtlibt  rnlirt . \gi  ntSijsIt  tn.  plnn.B  t.xU  nialStnti  i 
=  {futun  :  Prfdn'hdFuhirt\F]  \ 

(  3  AytiitSfjsti  niStarti[l)t  lihStati  [/■.].  I.  ]  • 
d  Agt^  ntSgxtf  niSlart\  —  jirstOf  (futiirt  i  A 
d AgentSystfrii  =  d Age7itSysteTn\  A 
intti-nnlStntt\.plan  =  plan  A 

{JirstOfi/utiirf  )).txif  rnalSlaU  =  d Fxtt  ninIStatf  1} 


An  agent  predicts  that  it  succeeds  when  started  in  a  particular  initial  world  state 
if  all  the  predicted  chronicles  from  that  initial  state  lead  to  success.  The  predicted 
success  function  maps  deliberative  agent  systems  to  the  set  of  worlds  where  the 
agent  predicts  it  will  succeed. 


prfdirtfdSurri-.ss  :  Siiiiplf  Agf  iitSystt  in  x  ('ontmlhr —  Fxti  riialDi  xcnption 

j  'i  age  nt.Systf  in  :  Siiiiph  Age  ntSiisF  in:  plan  :  Controlh  r  • 
predirtf  dSna  iss{  ageiilSystein.  plan }  = 

{w  :  (agfntSysteni).initialCi)ndilions  \ 

{'It  ar  :  Fredirtf  dChronidf  sOf  (agf  ntSystf  m.  plan,  w)  • 

(  3  r  :  pn fixf  sOf{chrnnirlt  Finjirti  nr))  • 

r  agf  nt.Systf  iii.iniliallnlf  nialStalf  Jash’.i  raluatmii  .ih  .■>/;»  d  i  1 } 


In  the  planning  process,  the  agent  revises  its  plan  attempting  to  improve  it. 
Occasionally,  the  agent  w  ill  adopt  a  revised  plan.  An  agent  is  rational  if  the  revised 
plan  it  adopts  is  predicted  to  be  at  least  as  successful  as  the  old  plan.  .-X  plan  is 
predicted  to  be  at  least  as  successful  as  another  plan  if  it  is  predicted  to  succeed 
under  a  superset  of  conditions  where  the  second  plan  is  predicted  to  succeed. 
This  definition  of  ration  is  very  restrictive.  A  preferable  definition  would  allow 
a  rational  agent  to  prefer  plans  where  the  predicted  probability  of  success  or  the 
expected  utility  is  higher.  This  requires  a  probability  distribution  over  possible 
events,  which  will  be  defined  later. 


_ RationalAgentSystem _ 

Simple  Agent  System 

V  update  :  controller  • 

(3  planBefore ,  plan  After  :  Controller  • 

planBefore  =  {stcond{first(  update))). plan  A 
planAfter  =  { secondi .second{  uj}date))).plan  A 
predicledSuccess{8.\gentSystem.  planBefore ) 

C  predictedSuccess(  0.\gentSystem,  plan  A  fter ) ) 


Sound  Agent 

A  sound  agent  is  predictive,  interpretive  and  rational.  That  is,  its  project  and 
interpret  relations  are  valid  and  it  selects  plans  that  it  predicts  will  succeed  under 
more  conditions. 

_ Sound  AgentSystem _ 

Predictive  AgentSystemlBinary  Evaluation] 

Interpretive  AgentSystem[Binary  Evaluation] 

RationalAgentSystem 


A  sound  agent  is  not  necessarily  successful.  The  agent’s  mechanism  may  not 
be  capable  or  perceptive  enough  to  accomplish  the  task.  In  such  a  case,  there  is 
no  plan  that  can  achieve  the  task.  Even  if  a  successful  plan  exists,  the  agent  may 
not  be  able  to  generate  it.  Just  because  an  agent  could  decide  correctly  whether 
a  plan  will  succeed  or  not,  does  not  mean  it  can  generate  a  successful  plan.  The 
agent’s  plan  generator  may  not  be  complete.  It  is  also  possible  that  it  may  take 
the  agent  too  long  to  generate  the  successful  plan.  A  complete  plan  generator  will 
eventually  generate  a  successful  plan,  if  one  exists,  but  by  the  time  it  has  done  so, 
some  deadline  for  the  task  may  have  passed. 


Utility  of  Task  Achievement 

When  we  talk  about  tasks  and  task  accomplishment,  we  recognize  that  some  ways 
of  achieving  a  task  are  better  than  others.  There  are  tradeoffs  that  must  be  made  in 
terms  of  efficiency,  resource  use  and  time.  One  method  of  taking  these  tradeoffs 
into  account  is  to  define  a  utility  function  over  possible  task  completions.  Such 
a  utility  function  maps  a  chronicle  to  a  number  that  indicates  the  quality  of  the 
chronicle  on  a  common  scale. 
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This  section  refines  the  definition  of  a  task  to  include  a  measure  of  utility  The 
utility  function  is  used  as  the  task  evaluation  function.  It  is  included  in  the  task 
definition  since  it  is  integral  to  what  it  means  to  accomplish  a  task.  Using  the 
utility  augmented  task  definition,  agent  properties  are  redefiried  as  partial  orders 
on  agent  systems.  It  is  then  possible,  for  example,  to  say  that  one  agent  system  is 
more  capable  than  another,  for  a  specific  task  in  a  specific  environment. 

A  utility  function  is  a  mapping  from  a  chronicle  to  a  utility  value. 

Utility  ==  ExternalChronicle  — ■  Z 

A  UtilityAgentSystem  is  an  agent  where  the  task  evaluation  function  is  a  utility 
function. 

_ UtilityAgentSystem - - - 

Simple  Delibernti  ve  Agen  tSys  tem[Utility] 


Relative  Agent  Properties 

Given  a  utility  task,  the  agent  properties  defined  above  can  be  refined  to  give  relative 
measures  of  those  properties.  The  definitions  below  give  dominance  relations  for 
each  property.  These  relations  are  only  partial.  They  indicate  when  one  agent 
system  is  clearly  better  than  the  other.  They  don’t  indicate  any  information  in  the 
case  where  one  is  sometimes  better  than  the  other  and  sometimes  worse. 

Relative  Success 

One  agent  is  at  least  as  successful  as  another  if  it  always  achieves  the  task  with 
equal  or  higher  utility  from  each  possible  initial  state. 

-  ^Successful  -  •  UtilityAgf  ntSysti  m  • —  UlilityAg<  i>tS!i.-'t(  m 
V  .s  I .  .s2  :  I  tililyAgf  ntSyst(  m  • 

•''  I  ^Successful  ■'’I  —Task  '' 

(V  ir  :  fi\  .inilinK  'oiiditions  • 

.'i  1  .f  vnliiationi  rhwniele  Urom(s  1 ,  tr ) ) 

>  s  1  .eralnntion{  rlironirleUromi  s2.  w))) 
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Relative  Capability 

An  agent  is  at  least  as  capable  as  another  if  its  mechanism  allows  it  to  accomplish 
the  task  with  equal  or  higher  utility  in  all  possible  circumstances.  This  is  made 
operational  by  saying  that  there  exists  an  agent  with  the  same  effectors  as  that  of 
the  first  agent  that  is  more  successful  than  all  of  the  agents  with  the  same  effectors 
as  the  second  agent. 

-  ^Capable  -  ■  Utility  Age  ntSijstf  ni  • — •  UtilityAgentSystfin 

Vsl,s2  :  Utility AgentSyslem  • 

si  ^Capable  O  sl  =Ta.sk  *2  A 

(3sl'  :  UtilityAgentSystem  •  .><1'  =Ta!ik  •'*1  ^ 

s  \  .mechanism. effects  =  s\' .mechanism. i  ffects  A 
(Vs2'  :  Utility. AgentSystem  •  (.s-2'  =Task  ^ 

.‘<2.  mechanism. effects  =  ■■<2'. mechanism. ffffcts)  => 

I  ^  Succe.ssfui  2  ) ) 


Relative  Perceptiveness 

An  agent  is  at  least  as  perceptive  as  another  if  its  sensors  provide  information 
that  allows  it  to  control  its  effectors  to  achieve  the  task  with  equal  or  higher  utility. 
Since  the  salient  sensor  information  depends  on  the  effectors,  we  will  only  compare 
agents  with  the  same  effectors. 

Relative  perceptiveness  is  made  operational  by  saying  that  there  exists  an  agent 
with  the  same  mechanism  as  that  of  the  first  agent  that  is  at  least  as  successful  as 
all  agents  with  the  same  mechanism  as  the  second  agent. 

-  ^Perceptive  -  •  Utility.Age  ntSystf  m  —  Utility.  \g(  ntSysti  m 
V  .v  1 .  .s2  :  (  tility.Agt  nt.Syst(  m  • 

.S' I  ^Perceptive  ■''2 

s\ .mtrhanism.t fftrts  —  .'•2.in(<hiini.'-m.<Jf<rl.'<  A 
(3  .s|'  :  I  lililyAgi  ntSysh  III  •  .s|  =  .si'  ' 
s  \  .1111  chani.'iiii  =  .•^\'.iinrliiiiii.''iii  A 
(V.s2'  ;  Utility.AgentSystun  •  (.s2  ^jask  ^ 
s2. mechanism  =  s2'  .nnehanism)  => 

•'’I  ^Successful  ■‘*2  )) 
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Relative  Reactivity 


Using  our  definition  of  reactive,  an  agent  is  more  reactive  than  another  if  it  acts 
appropriately  and  more  quickly  to  accomplish  the  task.  In  the  definition  below,  an 
agent  is  at  least  as  reactive  as  another  if  it  is  at  least  as  successful  and  accumulates 
utility  at  the  same  or  faster  rate. 

-  >Reaciivei  VtHityAijf  ntS(ji>lein  • — •  I  'lililijAijt  nt System 
V.sl.s2  :  UtilityAgentSystem  * 

si  ^Reactivel  ^2  0  ({sl  ^ Succes.sful  ^2)  A 

(V  w  :  s  \  .initialConelitions  • 

(Vel  ;  prefixesOf(rhrf)nu'leFrr)m(s\.w))\ 
cl  ;  prefixesOf  ( chronicle Frfjm(  s2.  w))  • 

#cl  =  #r2  => 

s\.tvaluntion(c\)  >  sl.evnliintion{c2)))) 


Relative  Reflexivity 

An  agent  is  at  least  as  reflexive  as  another  if  its  behaviour  matches  that  of  a  pure 
stimulus  response  system  to  the  same  extent.  The  idea  that  will  be  used  to  define 
relative  reflexivity  is  that  an  agent  that  behaves  in  a  way  that  requires  less  internal 
state  must  have  its  actions  dictated  by  a  control  function  that  is  closer  to  a  pure 
stimulus-response  system.  Note  that  a  more  reflexive  agent  does  not  necessarily 
have  less  internal  state,  it  just  behaves  in  a  way  that  requires  less  state. 

A  system  at  least  as  reflexive  as  another  if  it  behaves  in  a  way  that  require  less 
memory.  The  function  minCtrStates  is  used  to  determine  the  amount  of  memory 
required  for  the  behaviour  of  each  agent. 

-  ^Reflexive  -  ■  Ft  Hit  ijAye  ntSyste  ni  —  I’tilityAye  ntSysIt  m 

s  \ .  s2  :  (  tilityAyf  ntSyste  in  * 

•'<1  >Renexivc  •‘’'2  s\  =7^^^  .'•2  A 
I  {  minCtrStnte  s{  s]  )  <  niiiiCtrStiiti  s(s2)) 


Relative  Predictiveness 

An  agent  is  at  least  as  predictive  as  another  if  its  prediction  relation  is  more  accurate. 
Mistakes  in  the  prediction  relation  can  be  of  two  types.  The  prediction  function 
can  omit  correct  predictions  and  can  include  incorrect  predictions.  An  agent  is 
more  predictive  than  another  if  its  correct  predictions  are  a  superset  of  the  correct 
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predictions  of  the  second  agent  and  its  omissions  are  a  subset  of  the  omissions  of 
the  second  agent.  Only  agents  with  the  same  environment  and  effectors  can  be 
compared  for  predictiveness. 

The  definition  of  >  Predictive  makes  use  of  the  correctProject  function.  The 
correctProject  function  is  used  to  generate  the  valid  projection  relation,  pr.  The 
correct  projections  made  by  each  of  the  agent’s  project  relations  are  their  projection 
relations  intersected  with  the  correct  projection  relation.  The  correct  projections 
of  the  first  agent  are  required  to  be  a  superset  of  those  of  the  second  agent.  The 
project  relation  of  each  agent  minus  the  correct  projections,  pr,  gives  the  set  of 
incorrect  predictions.  The  incorrect  predictions  of  the  first  agent  must  be  a  subset 
of  those  made  by  the  second  agent. 

-  ^Predictive  -  ^  Utility AgentSystem  • — •  UtilityAgentSystem 

Vs1.52  :  UtilityAgentSystem  • 

si  ^Predictive  ^2  O  (-Sl  =Tx<ik  -^2  A 

si. mechanism. effects  =  .sl.mechanism. effects  A 
( 3  pr  :  Project  Relation  • 

pr  =  correctProject{s\. environment,  si. mechanism)  A 
(pr  n  sl.initialInternalState. project) 

C  (pr  n  si. initialInternalState. project)  A 
( si  .initiallnternalState. project  \  pr) 

C  {s2. initiallnternalState. project  \pr))) 

Relative  Interpretiveness 

An  agent  is  at  least  as  interpretive  as  another  if  its  interpret  relation  makes  the  same 
or  fewer  mistakes.  That  is,  if  the  incorrect  interpretations  included  in  its  interpret 
relation  are  a  subset  of  the  incorrect  interpretations  of  the  other  agent  and  its  correct 
interpretations  are  a  superset  of  the  other  agent’s  correct  interpretations. 

-  > Imerpreiive  -  •  Utility,  ige  ntSy!<tf  m  • —  UtilityAgrntSysh  ni 

V  .s  1 ,  .s2  :  [  tility.  igt  nt.Sy.'^tt  in  • 

•‘’1  ^Interpretive  ■'’2  <!=!>( -S  1  =Task  A 

si  .mechanism. perceive  =  s2. mechanism. jierceive  A 

{.s2. initiallnternalState. interjiret  n  si  .mechanism. ixrceire  )  C 

{.si. initiallnternalState. interpret  D  si. mechanism. perceive)  A 
{si  .initialinternalState .interpret  \  si  .mechnni.sm.perceive  )  C 

( .s2.initieilInternnl.Steite.interpvf:t  \  s  I  .niechanism.pe  n  e  ive ) ) 
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Utility  based  Rationality 

With  a  utility  based  measure  of  success,  we  can  retine  the  meaning  of  rational. 
An  agent  is  rational  if  it  adopts  plans  with  a  higher  utility  over  plans  with  a  lower 
utility.  The  problem  with  this  definition  is  that  plans  typically  have  a  range  of 
predicted  utility.  Each  plan  has  a  set  of  predicted  outcomes  and  each  outcome 
has  a  different  utility.  When  we  define  a  probability  distribution  over  predicted 
outcomes,  we  can  use  expected  utility  for  each  plan  to  define  rational.  For  now, 
a  utility  based  rational  agent  is  one  that  prefers  plans  that  have  at  lease  as  high  a 
minimum  predicted  utility  in  all  possible  starting  conditions. 

To  assist  with  the  definition  of  a  UtilityRationalAgentSystem,  we  define  a 
function  that  takes  an  agent,  a  plan  and  an  initial  external  state  and  returns  the 
minimum  predicted  utility. 

predicted  Utility  :  Utility  AgentSrjstem  x  Controller  x  ExtemnlStnte  — ■  Z 

V  Utility AyentSystenv,  plan  :  Controller  • 

(V  u)  :  initialConditions  • 
predictedUtility(6AgentSystem, plan,  w)  = 

min({ac  :  PredictedClironiclesOf(OAgentSystem,  plan,  w)  • 

initiallnternalState  .task  .evaluation{  chronicle  Project  (nr))} ) ) 

A  UtilityRationalAgentSystem  will  only  update  its  plan  if  the  new  plan  has  at 
least  the  same  minimum  predicted  utility  in  each  possible  starting  condition. 

_ UtilityRationalAgentSystem _ 

Utility  AgentSy  stem 

V  update  :  controller  • 

(3  planBefore .  plmiAfter  ;  Controller  • 

planBefore  —  (second(Jirst\ui)date))).plan  A 
plan  After  =  {serond(second(iqulate))).plan  A 
(V  w  :  initiaK.'ondition.'i  • 

pr(  dictedUtility(0  Agenl.Syslem.  plnnBefon  ,  w) 

<  pri  dicte  dUtililyl  ffAgi  ntSysh  in.  plan  A  fli  r.  //’))) 

Relative  Soundness 

An  agent  is  at  least  as  sound  as  another  if  it  is  at  least  as  predictive  and  interpretive 
and  it  is  rational.  That  is,  its  project  and  interpret  relations  are  as  good  or  better 
and  it  selects  plans  that  are  predicted  to  have  a  higher  minimum  utility. 


40 


-  >Sound  -  ■  U tility Rational AgentSy stem  - — •  UtilityRationalAgentSystem 


Vsl,s2  ;  U tility AgentSystem  • 

Si  ^ Sound  ■>—  vi  (^1  ^Predictive  ^ 
■sl  ^Interpretive  ^2) 


Expected  Task  Performance 

The  relations  defined  in  the  previous  section  for  agent  comparisons  are  generally 
inadequate  for  common  use.  It  is  not  the  case  that  one  agent  will  always  dominate 
another  in  terms  of  its  performance.  For  most  agents,  there  are  tradeoffs  that  are 
made  that  allow  the  agent  to  perform  better  in  some  cases,  but  not  it  others.  When 
evaluating  performance,  the  distribution  of  situations  must  be  taken  into  account 
to  give  the  expected  performance  of  the  agent. 

To  evaluate  expected  performance,  a  probability  distribution  over  possible 
initial  states  is  needed.  Using  a  probability  distribution,  it  is  possible  to  determine 
the  expected  success.  This  is  done  by  determining  the  performance  in  each  possible 
initial  state  and  weighting  this  performance  by  the  probability  of  the  initial  state. 
Agent  properties  that  are  defined  in  terms  of  success  can  then  be  refined  to  take  the 
relative  distribution  of  states  into  account. 

Probability  Schemas 

For  the  purposes  of  this  specification,  a  discrete  probability  distribution  will  be 
represented  as  a  “bag”  of  the  appropriate  items.  The  count  ot  each  item  in  the  bag 
will  be  proportional  to  the  frequency  of  that  event  in  the  probability  distribution. 
The  probability  of  a  particular  item  is  the  count  of  the  item  divided  by  the  sum  of 
the  counts  of  all  the  items  in  the  bag. 


Distribution  :  P(bag.\  ) 


The  purpose  of  using  a  distribution  is  to  weight  possible  outcomes  by  their 
probability.  The  generic  function  probability  takes  an  item  and  a  distribution 
and  returns  an  ordered  pair  (n,m)  representing  the  probability  of  the  item  in  the 
distribution  as  “n  out  of  m”.  The  generic  weight  function  takes  a  probability 
distribution  and  a  function  that  maps  an  item  to  a  number.  The  weight  function 
applies  the  function  it  is  passed  to  each  item  in  the  Distribution  and  sums  the 
results,  weighting  each  by  the  probability  of  the  item  in  the  distribution. 
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—  L-'  J .  .  '  - - - - -  - 

pmbnbUity  :  {X  x  Distribution[X]}  — •  (Z  x  Z) 
weight  :  (A'  — •  Z)  x  Distribtttion[X]  — '  Z 

Vz  :  A';  d  :  Distribution[X]  •  probability (x,d)  =  (count(d){i).#d) 

V /  :  A'  — ^  Z;  d  :  Distributio;i[Xl  * 

weight(f.d)  =  probabtlity(x ,  d)  *f{x)f 


Expected  Performance  Evaluation 

An  expected  performance  task  evaluation  function  is  an  extension  of  the  utility 
task  evaluation  function.  Expected  performance  evaluation  depends  on  the  utility 
function  and  the  initial  distribution.  The  expected  performance  is  calculated  by 
weighting  the  utility  of  the  performance  in  each  situation  by  the  probability  of  that 
situation. 

ExpectedEvaluation - 

utility  :  Utility 

initial  Distribution  :  Distribution[ExtemalState] 


An  ExpectedAgentSystem  is  a  SimpleDeliberativeAgentSystem  with  an  ex¬ 
pected  evaluation  function. 

_ ExpectedAgentSystem _ 

Simple  Deliberative  AgentSystem[ExpectedEvaluation] 


Expected  Success 

The  expected  success  of  an  agent  is  just  the  performance  of  an  agent  for  each 
possible  initial  state  weighted  by  the  probability  distribution  of  the  initial  state. 

First  we  define  a  performance  function  that  takes  an  ExpectedAgentSystem 
and  returns  a  function  that  maps  ExtemalStates  to  performance. 

performance  :  ExpectedAgentSystem  — ■  (  ExternalStnte  — •  Z) 

V  ExpectedAgentSystem-,  ExternalState  • 

performancei  9  ExpectedAgentSystem  ){9  ExternalState )  = 

evaluation . utility ( chronicle From(  9  Expected AgentSxystem .  9 ExternalState ) ) 

■‘Not  .strictly  Z  code 
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Then  we  define  an  expected  success  function  that  takes  an  ExpectedAgentSys- 
tem  and  returns  the  expected  performance. 

expectedS access  :  ExpectedAgentSgstem  —  Z 

V  ExpectedAgentSystem  • 

expectedSuccess(  0  ExpectedAgentSystem )  = 

weight(i)erfonnance(B  ExpectedAgentSystem ).  evaluation,  initial  Distribution  ) 


Expected  Capability 

Expected  capability  reflects  the  ability  offflBttagetnt’actfeve  the  task. 

It  is  defined  to  be  the  best  expected  performance  that  could  be  achieved  with  the 
same  set  of  effectors  doing  the  same  task.  One  mechanism  is  more  capable  than 
another,  in  an  expected  value  sense,  if  it  has  a  higher  expected  capability. 

expectedCapability  :  ExpectedAgentSystem  —  Z 

V  ExpectedAgentSystem  • 

expectedCapability(d  ExpectedAgentSystem )  = 
max(  {ExpectedAgentSystem'  1 

(9 ExpectedAgentSystem  =Ta.sk  9 ExpectedAgentSystem' )  A 
(mechanism. effects  =  mechanism'  .effects) 

•  expectedSuccess(9 ExpectedAgentSystem')} ) 

Expected  Perceptiveness 

Expected  perceptiveness  reflects  both  the  capability  of  the  agents  effectors  and  the 
perceptiveness  of  the  agents  sensors.  The  expected  perceptiveness  of  an  agent  is 
the  maximum  expected  success  of  any  agent  with  the  same  mechanism.  With  this 
definition  of  perceptiveness,  the  expected  perceptiveness  will  always  be  less  than 
or  equal  to  the  expected  capability. 

f  xpf  ctf  d Pf  rcf  pi ivf  in  ss  :  E.A'pi cl<  d.  \grnlStislr  m  —  Z 

V  ExpectedAgentSystem  • 

expectedPerceptivene.ss(  9  ExpectedAgentSystem )  = 
max({  ExpectedAgentSystem'  | 

(9 ExpectedAgentSystem  =Task  9 ExpectedAgentSystem' )  A 
(mechanism  —  mechanism') 

•  expectedSucce.s.s(9 Expect ed.\gent System')]  ) 
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General  Task  Properties 

Up  to  this  point,  we  have  considered  properties  of  agents  in  relation  to  the  task 
and  the  environment.  In  this  section,  we  consider  tasks  in  relation  to  all  possible 
agents.  This  allows  us  to  define  properties  of  tasks  and  to  categorize  tasks  as  shown 
in  figure  7. 

The  categorization  of  tasks  depends  heavily  on  the  .set  of  agents  that  are  consid¬ 
ered  possible.  Clearly,  the  task  of  going  to  the  moon  and  returning  moon  rocks  is 
achievable  only  if  we  allow  autonomous  rockets  as  possible  agents.  Changing  the 
set  of  possible  agents,  changes  the  set  of  tasks  that  are  achievable.  Similarly,  the 
set  of  tasks  in  other  categories  also  changes  as  the  set  of  possible  agents  changes. 

Detailed  explanations  of  each  category  of  task  follow. 


Consistent  Tasks 

It  is  possible  that  a  task  can  be  internally  inconsistent.  There  may  be  some 
conditions  under  which  there  is  no  way  of  achieving  the  task.  In  this  framework, 
an  inconsistent  task  corresponds  to  a  binary  task  where  there  is  no  desired  chronicle 


44 


that  begins  in  one  or  more  of  the  possible  initial  states.  An  inconsistent  task  cannot 
be  accomplished  by  any  agent.  A  classic  example  of  such  a  task  is  requiring  the 
agent  to  be  in  two  places  at  the  same  time. 

_ ConsistentTask _ 

Binary  Task 

V  w  ;  initialConditions  • 

3  chronicle  :  evaluation. desired  • 
w  =  firstOf  (chronicle) 


Inconsistent  tasks  are  the  complement  of  consistent  tasks. 

InconsistentTask  =  Binary  Task  A  ->  ConsistentTask 

Achievable  Tasks 

It  is  possible  that  a  task  is  consistent  yet  sti!'  cannot  be  achieved  by  any  one  agent. 
Suppose  the  task  were  to  recover  the  black  box  recorder  from  a  crashed  airplane. 
The  possible  agents  are  walking  robots  and  autonomous  submarines.  If  the  airplane 
crashes  on  land,  then  the  robot  can  recover  the  recorder.  If  it  crashes  in  the  ocean, 
then  the  submarine  can  recover  it.  The  problem  is  that  the  submarine  cannot  travel 
on  land  and  the  robot  cannot  operate  under  water.  The  task  is  consistent  since 
there  is  always  some  way  of  achieving  it.  However,  it  is  not  achievable  by  a  single 
agent  in  the  set  of  possible  agents.  If  a  walking  submarine  were  added  to  the  set  of 
possible  agents,  then  the  task  would  be  achievable. 

The  tasks  that  can  be  achieved  by  a  single  agent  are  achievable  tasks. 

_ .Achievable  r«^A:[5] _ 

Consistent  Task 

3  Succe.ssful.Agent,Systf:ni'[.S]  • 

0  Task  =  0  Task' 


Independent  Tasks 

There  are  some  tasks  where  the  agent  has  no  influence  over  whether  the  task  is 
achieved  or  not.  The  achievement  of  these  tasks  is  independent  of  the  actions 
of  any  possible  agent.  For  example,  consider  the  task  of  getting  a  particular  star 
to  go  supernova  at  a  particular  time.  The  star  either  will  go  supernova  or  not, 
independent  of  what  the  agent  does. 
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We  define  an  independent  task  to  be  a  task  where  if  one  agent  succeeds  in  a 
given  set  of  initial  conditions,  then  all  agents  will  succeed,  given  the  same  initial 
conditions. 

_ IndependentTask[S\ _ 

Binary  Task 

V  w  :  initialConditions  • 

(V  AgentSystem'[S ,  Binary  Evaluation]  • 

{9  Task  =  9  Task']  => 

(prefixesOf  (chronicle  From(9  AgentSystem' .  id))  H  evaluation  .desired  =  0)) 
V  {'i  AgentSystem' [S .  Binary  Evaluation]  • 

9  Task  =  9  Task' 

(prefixesOf (chronicleFrom(9. AgentSystem' ,w))  C\  evaluation. desired  0)) 


Inevitably  Achievable  Tasks 

A  task  will  be  achieved  inevitably  if,  for  all  agents,  all  possible  future  states  of  the 
world  are  in  the  set  of  desirable  future  states.  In  this  type  of  situation,  the  agent  can 
do  no  wrong.  Consider  as  an  example,  an  agent  that  is  given  the  task  of  getting  the 
sun  to  rise  tomorrow  morning.  No  matter  what  the  agent  does,  the  sun  will  rise. 
(Although  you  may  not  be  able  to  see  it  behind  the  clouds.) 

An  inevitable  task  is  a  task  that  is  achievable  and  is  independent  of  the  particular 
agent. 

Inevitable Task[S]  =  Ind€i)endenlTask[S]  A  .Achie cable Task\S] 

Default  Task  Achievement 

Some  tasks  are  possible  to  achieve  by  doing  nothing  and  cannot  be  achieved  if  the 
agent  does  the  wrong  thing.  These  ta.sk.s  are  achieved  by  default.  For  example,  if 
we  give  the  agent  the  task  of  watering  the  lawn,  and  it  is  raining,  there  is  nothing 
the  agent  has  to  do  to  complete  the  task.  Note  that  this  is  not  necessarily  the  same 
as  an  inevitable  task.  The  agent  could  hold  a  large  umbrella  over  the  lawn  and 
prevent  it  from  getting  wet.  The  agent  can  perform  actions  that  will  not  accomplish 
the  task. 

The  problem  that  must  be  addressed  in  this  definition  is  “What  does  it  mean  for 
an  agent  to  ‘do  nothing.’  ”  Even  when  we  are  doing  nothing,  we  are  still  breathing 
and  growing  hair. 
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To  get  around  this  problem,  we  designate  one  of  the  COMMANDS  for  each 
agent  to  be  the  “do  nothing”  or  null  command.  When  this  COMMAND  is  sent  to 
the  mechanism,  the  mechanism  does  its  own  version  of  nothing. 

I  NullCommand  :  COMMAND 

A  default  task  is  a  task  that  an  agent  can  achieve  by  executing  only  NullCom- 
mands.  To  ensure  that  there  are  also  ways  to  not  achieve  the  task,  default  tasks  are 
restricted  not  to  be  independent  and  thus  not  inevitable. 

_ Default  Achievable  TasA:[5] _ 

Achievable  Ta*^[5] 

->  IndependentTask[S] 

3  SuccessfulAgentSijstem'[S]  • 

OTask  =  8  Task'  A 

ctrCommands(  controller')  =  {NullCommand} 


Future  Work 

The  current  specification  does  not  deal  with  learning.  There  is  no  definition  of 
learning.  It  is  suggested  that  a  deliberative  agent  could  learn  by  becoming  more 
predictive,  interpretive  and  rational.  While  this  is  probably  correct,  the  issues  in 
learning  have  more  to  do  with  how  well  the  learner  generalizes.  How  performance 
of  one  task  can  improve  performance  of  related  tasks.  To  do  this,  some  method  is 
needed  for  talking  about  related  tasks. 

A  second  major  direction  for  future  work  is  to  define  the  deliberative  prop¬ 
erties;  predictive,  interpretive  and  rational,  in  terms  of  the  expected  distribution 
of  external  states.  It  is  more  important  to  make  correct  predictions  in  situations 
that  are  more  likely  to  occur.  Such  definitions  would  result  in  a  finer  scale  for 
measuring  these  properties.  This  would  be  useful  when  defining  learning  agents. 
The  problem  in  doing  this  is  that  the  agent  selects  its  actions  based  on  its  mod¬ 
els.  Changing  the  model  could  change  the  actions  selected  and  thus  change  the 
expected  distribution  of  external  states.  Any  dehnition  must  take  this  shifting  of 
external  state  distributions  into  account. 

Another  direction  for  future  work  would  involve  applying  the  framework  de¬ 
veloped  in  this  specification  to  an  actual  agent  system.  This  would  involve  tailoring 
the  representations  of  the  agent,  the  task  and  the  environment  for  the  particular 
system.  Abstract  definitions  would  have  to  be  made  operational.  For  instance. 
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the  evaluation  function  for  a  binary  task  could  not  be  represented  as  an  infinite 
set  of  infinitely  detailed  Chronicles.  Extending  this  idea,  multiple  agents  could  be 
formalized  and  compared. 


Conclusions 

This  paper  has  presented  formal  definitions  for  some  properties  of  agents  that 
perform  tasks.  For  a  general  class  of  agents  we  have  defined  successful,  capable, 
perceptive  reactive  and  reflexive.  In  addition,  predictive,  interpretive,  rational  and 
sound  were  defined  for  deliberative  agents.  These  definitions  have  been  given  in 
terms  of  a  framework  for  discussing  agents,  tasks  and  environments.  Through 
developing  this  framework,  we  h.ave  identified  some  important  issues  that  any 
work  in  this  area  should  address.  These  issues  include  how  to  represent  time, 
non-determinism  and  interaction  between  the  agent  and  the  environment. 

It  is  intended  that  the  definitions  and  framework  presented  in  this  paper  be 
useful  for  analyzing  and  comparing  agents.  It  is  also  hoped  that  this  work  will 
help  to  foster  discussion  by  providing  a  common  and  well  defined  vocabulary  for 
talking  about  environments,  tasks  and  agents. 
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A  Z  primer 


This  appendix  contains  a  short  introduction  to  the  Z  specification  language.  Its  aim 
is  to  provide  sufficient  detail  about  the  language  to  allow  someone  familiar  with 
standard  mathematical  nutation  to  be  able  to  understand  the  specifications  given  in 
this  report.  For  a  more  complete  introduction  to  Z  see  [Spivey,  1989]. 

In  this  explanation,  a  simple  specification  for  a  library  will  be  used  as  an 
example.  The  library  will  consist  of  a  set  of  books  and  a  card  catalog.  The 
example  is  very  simple,  but  uses  most  of  the  Z  notation  needed  to  understand  the 
agent  properties  specification. 

Primitive  Data  T^pes 

A  primitive  data  type  has  no  structure  and  no  details  are  given  about  how  the  data 
type  might  be  implemented.  For  the  library,  the  basic  data  types  needed  are  : 

[BOOK,  CATALOGNUM ,  STRING] 

Primitive  data  types  are  written  in  all  capitals  by  convention. 

Abbreviations 

It  is  often  useful  to  abbreviate  type  definitions.  Below  a  Bundle  is  defined  to  be 
an  abbreviation  for  a  set  of  books.  The  P  before  the  BOOK  is  used  to  indicate  the 
power  set  of  all  BOOKs. 

Bundle  ==  P  BOOK 

Axiomatic  Definitions 

Functions  and  variables  can  be  declared  as  axiomatic  for  the  definition.  The 
function  titleOf  defined  below  is  a  function  that  maps  BOOKs  to  STRINGS.  It 
is  a  function  since  each  BOOK  is  mapped  to  a  single  STRING.  In  an  axiomatic 
definition,  the  functions  and  variables  are  declared  above  the  horizontal  line.  Below 
the  line,  any  restrictions  imposed  on  the  definitions  are  given.  In  this  case,  the 
restriction  says  that  the  number  of  elements  in  the  domain  of  the  function  is  greater 
than  or  equal  to  the  number  of  elements  in  the  range  of  the  function.  In  other  words, 
the  number  of  BOOKs  is  greater  than  or  equal  to  the  number  of  titles.  There  can 
be  more  than  one  book  with  the  same  title,  but  one  book  can’t  have  two  titles.  In 
the  Z  notation,  ran  and  dom  are  short  for  range  and  domain  respectively.  The  “#” 
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sign  indicates  a  count  of  the  number  of  items  in  a  set.  Functions  are  indicated  with 
“ — ■”  and  partial  functions  are  indicated  with  “-h-”.  Relations  are  indicated  with 
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titleOf  :  BOOK  —  STRING 
#(dom  titleOf)  >  #(ran  titleOf) 

The  variable  “childrensBooks”  is  declared  as  a  globally  defined  bundle  of 
books. 

I  childrensBooks  ;  Bundle 

Schemas 

Schemas  are  used  to  specify  composite  data  types  similar  to  records.  The  schema 
name  appears  at  the  top  of  the  schema  box.  As  with  axiomatic  definitions,  the  type 
declarations  are  separated  from  predicates  that  restrict  them  by  a  horizontal  line. 

The  library  schema  is  composed  of  a  collection,  a  catalog  and  a  numbering 
of  BOOKS.  The  collection  is  a  Bundle,  or  set  of  books.  The  catalog  is  a  partial 
function  that  maps  titles  (STRINGs)  to  CATALOGNUMs.  The  numberOf  partial 
function  assigns  CATALOGNUMs  to  particular  books. 

Below  the  horizontal  line  a  number  of  restrictions  on  the  elements  of  the  library 
schema  are  specified.  All  BOOKs  in  the  collection  are  included  in  the  range  of 
the  partial  function  numberOf.  Also,  the  title  of  every  BOOK  in  the  collection 
is  in  the  catalog.  Furthermore,  for  every  CATALOGNUM  in  the  catalog,  there 
is  a  BOOK  in  the  collection.  The  between  the  quantified  variables  and  the 
following  expression  is  just  a  separator. 

_ Library _ 

collfction  ;  Bundle: 

ratnloy  :  STRING  ^  ( '.1  TA  LOGNl'M 
numberOf  :  BOOK  -4-  CA  TA  LOGNl’M 

V  b  :  collection  • 

(  6  €  (dom  numberOf )  A 
titleOf  (b)  e  (dom  cataloy)} 

V c  :  (ran catalog)  • 

(36:  collection  • 

numberOf  {  b)  =  c] 
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Schemas  can  also  be  refined  to  produce  specializations.  Below  a  children’s 
library  is  defined  to  be  a  library  where  all  the  books  in  the  collection  are  children  s 
books.  All  components  of  the  library  schema  and  the  restrictions  placed  on  them 
are  also  part  of  the  childrensLibrary  schema. 

_ ChildrensLibrary _ 

Library 

collection  C  childrens  Books 


When  schemas  are  used  in  quantified  expressions,  the  0  operator  can  be  used  to 
refer  to  the  entire  schema.  The  definition  of  collectionSize  below  maps  a  library  to  a 
number  books  in  its  collection  Within  the  scope  of  the  V,  the  entire  library  schema 
can  be  referred  to  using  9 Library .  It  is  convenient  to  read  this  as  “theLibmry".  9 
can  be  used  where  ever  the  Library  being  referred  to  is  obvious  from  the  context. 
Individual  components,  like  collection  can  be  referenced  directly. 

collectionSize  :  Library  — •  Z 
V  Library  •  collectionSize{9 Library)  =  ttcollection 
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